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