AFAIK, we can't derive the spec version of an application by looking at
the descriptor version. e.g., just because an application uses EE 5
schema, it does not mean it is not an EE 6 application. For this reason,
in verifier, we always had an explicit specVersion option which user had
to specify if they wanted to verify against a particular specification.
By default, verifier sets the specVersion to the highest version of the
spec. I expect similar behavior in GlassFish as well. I have not read
the new specs lately, but I would expect the new class loading
restrictions to be applicable to all the applications irrespective of
their descriptor version except for applications deployed with
jarVisbility=v2 option.
It will be good to have a similar property in sun-*.xml so that
applications deployed via autodeploy dir or other means can use the
facility.
Thanks,
Sahoo
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
>