On Aug 19, 2009, at 1:22 PM, Bill Shannon wrote:
> Our hope is that very few applications depend on this non-portable
> behavior. If you have evidence otherwise, please let us know.
>
> To clarify... While this issue was raised in the context of app
> clients,
> are they the only module type that's impacted by the new Java EE 6
> rules?
AFAIK, every Java EE module (packaged within a .ear file of course) is
susceptible to this.
>
> I think it's reasonable that applications present during an upgrade
> are marked so that they will get behavior compatible with the previous
> release. Ideally, you would be able to detect whether there *are* any
> jar files that would not otherwise be accessible to the app client,
> and
> only mark the app in that case, while also emitting a warning. It's
> probably best if this flag persists across a redeploy, but I don't
> expect it to persist across an undeploy/deploy.
>
> And in case it's not clear, it would be best if this flag was on a
> per application granularity, rather than effecting the entire app
> server.
it is indeed per application, but all upgraded applications would have
the flag.
>
>
> Sahoo wrote on 08/19/09 01:27:
>> If I were a product owner, I would worry more about compatibility
>> than spec compliance. Anyway, that's a perspective difference I
>> suppose. As a user, I prefer #2 for the simple reason that my
>> application is already fine with the old visibility mode, why
>> switch to a new mode for an existing app. If I am writing a new
>> app, I will certainly worry about portability and hence I like the
>> default being new mode.
>> BTW, should we make this an upgrade option? In any case, I suggest
>> we make this configurable and then we can just decide what is the
>> default value based on feedback.
>> Finally, on a second thought, I think we can rename the deploy
>> option from "jarVisibility" to something like "compatibility" so
>> that we can use the same flag any other compatibility issues. Then,
>> we don't need yet another option when move to next version. We can
>> just have --compatibility=v3 while running in v3++.
>> What do people think?
>> Thanks,
>> Sahoo
>> Jerome Dochez wrote:
>>> this does pose a number of significant compatibility issues. For
>>> instance, take an upgrade scenario, where applications (using that
>>> behavior) were deployed successfully will not be able to be
>>> upgraded to V3 without requiring the usage of the flag.
>>>
>>> So we seem to be stuck between two equally bad choices :
>>> 1. we don't run the upgrade redeployment with the flag and
>>> applications that were not flagged as using a deprecated or
>>> incorrect feature in V1/V2 will fail to be upgraded correctly.
>>> 2. we run with the flag which mean that we automatically upgrade
>>> and run the already deployed applications in an incompatible mode.
>>>
>>> Even in normal re-deployment scenarios, applications will fail to
>>> redeploy with confusing errors (class not found exceptions most
>>> likely) while they deployed without an itch in v2. We seem to be
>>> breaking basic binary compatibility.
>>>
>>> To come back to upgrade, as a product owner, I prefer 1), spec
>>> writers will prefer 2), users will be confused anyhow :)
>>> votes ?
>>>
>>> jerome
>>>
>>> On Aug 18, 2009, at 11:47 AM, Bill Shannon wrote:
>>>
>>>> Roberto (and Sahoo) are exactly right.
>>>>
>>>> The version number in a deployment descriptor does *not* mean
>>>> "this is
>>>> the version of the platform I'm expecting". It only means "this
>>>> is the
>>>> version of the data file format you're about to read". Changing
>>>> the
>>>> behavior of the platform based on the data file format is a
>>>> mistake.
>>>> (Sadly, it's a mistake we've made a few times, but not one we
>>>> should
>>>> keep making.)
>>>>
>>>> Ideally, the CTS would test that the behavior is correct
>>>> independent
>>>> of the deployment descriptor version number.
>>>>
>>>> Using a deployment property to explicitly override the normal
>>>> visibility
>>>> rules is allowed by the spec in this case, and is an appropriate
>>>> solution.
>>>> Providing a way to set this property in a product-specific
>>>> deployment
>>>> descriptor would also be acceptable.
>>>>
>>>>
>>>> Roberto Chinnici wrote on 08/18/09 11:24:
>>>>> Typically we don't base container behavior on the version of the
>>>>> deployment descriptor present in an app or module.
>>>>> It seems to me that the "EE 6 restrictions" should be honored
>>>>> regardless of the descriptor version.
>>>>> The property in (3) could then be used to override the
>>>>> restrictions for apps that either don't have a descriptor or
>>>>> have an EE 5 one.
>>>>> --Roberto
>>>>> Tim Quinn wrote:
>>>>>> On the arch mailing list this past spring we started this
>>>>>> discussion but never closed on it. I followed up with a
>>>>>> message on that list on Aug. 7 but heard no response so I am
>>>>>> moving the discussion to this list and proposing a path forward
>>>>>> that was talked about in this week's v3 engineering meeting.
>>>>>>
>>>>>> The Java EE 6 platform spec imposes stricter requirements than
>>>>>> EE 5 on what JARs are to be visible to the various submodules
>>>>>> of an application. Sections EE 8.3.1 (web), 8.3.2 (EJB), and
>>>>>> 8.3.3 (app client) in particular list the JARs that submodules
>>>>>> must, may, and must not have access to.
>>>>>> In particular, and of particular interest to me, the spec
>>>>>> mandates that app clients must not have access to EJB JARs or
>>>>>> other JARs in the EAR unless references using the standard Java
>>>>>> SE mechanisms (extensions, for example) or the EE library-
>>>>>> directory mechanism.
>>>>>>
>>>>>> In GlassFish v2 and earlier, in addition to these JARs app
>>>>>> clients had access to EJB JARs and any JAR at the top-level of
>>>>>> the EAR. (This feature predated the Java EE 5 library-
>>>>>> directory feature for EARs.)
>>>>>>
>>>>>> The proposal from today's engineering meeting is this:
>>>>>>
>>>>>> 1. GlassFish v3 will inspect the schema version referenced in
>>>>>> the application.xml (if present). If the schema is for EE 6
>>>>>> then GlassFish v3 will honor the EE 6 restrictions. If the
>>>>>> schema is for EE 5 or earlier then GlassFish v3 will behave as
>>>>>> GlassFish v2.
>>>>>>
>>>>>> 2. GlassFish v3 will treat an application with no descriptor as
>>>>>> an EE 6 app and will enforce the EE 6 restrictions.
>>>>>> 3. Users might have existing apps which depend on the v2
>>>>>> behavior and which do not have descriptors. To handle this
>>>>>> case the deploy command will support a property that overrides
>>>>>> the schema version (whether explicit as in #1 or defaulted as
>>>>>> in #2).
>>>>>> We did not discuss how to name this property. Some options:
>>>>>>
>>>>>> deploy ... --property jarVisibility=javaee5 (or javaee6)
>>>>>> [referring to the EE spec version]
>>>>>>
>>>>>> deploy ... --property jarVisibility=v2 (or v3) [referring to
>>>>>> the GlassFish version]
>>>>>>
>>>>>>
>>>>>> Because part of the solution is to examine the schema version
>>>>>> in application.xml (which is related to the Java EE version) it
>>>>>> might be clearer to have the property refer to the EE version
>>>>>> also.
>>>>>>
>>>>>>
>>>>>> Please respond to this message with feedback, concerns,
>>>>>> questions, etc. Ideally we would take care of this issue this
>>>>>> week before the soft code freeze (next Monday).
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> - Tim
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>