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
>>
>