Hi, all.
Given that the EE 6 spec is much more restrictive than EE 5 about what
JARs should be available to app clients -- specifically:
> Components in the application client container must not have access to
> the
> following classes and resources, unless such classes or resources are
> covered by
> one of the rules above.
> • Other classes or resources in the application package. For example,
> the appli-
> cation client should not have access to the classes in other
> application client jar
> files in the same ear file, nor should it have access to the classes
> in web appli-
> cations or ejb jar files in the same ear file.
we need to reconcile this with GlassFish v2 behavior in which app
clients had access to EJB modules automatically (and users have
complained about that) as well as JARs at the top-level of the EAR.
1. I propose that we NOT make EJB JARs accessible (unless, of course,
the developer uses the Class-Path entry in the app client JAR's manifest
to do so him/herself).
2. As for top-level JARs, if we adhere to the spec we risk breaking some
working app clients. If we preserve backward compatibility on this we
will be out of spec compliance.
The EE 6 spec does say this:
> Other classes or resources contained in the application package, and
> specified
> by an explicit use of an extension not defined by this specification.
I propose that we exclude top-level JARs from app clients unless the
user specifies such an "explicit extension" by setting a property on the
deploy command, such as
deploy ... --properties clientIncludesTopLevelJars=true
or some other name. I'm particularly interested in excluding top-level
JARs unless the users requests them to keep the size of the downloaded
app client as small as possible.
I just learned that a conscious decision was made that the server-side
would not conform to this provision of the spec but would let modules
see top-level JARs as in the past.
Was a deployment-time option considered and dismissed for the server
side behavior? It seems to me that even better than an
app-client-specific property would be a deployment-time property that
applies to all modules in the app, including app clients, such as
includeTopLevelJars
(or some better name). It would bring us into compliance while
introducing a backward incompatibility that's easily remedied by one
deployment-time option.
But I don't know what has already been discussed and I don't know
people's preferences when spec compliance and backward compatibility
collide.
- Tim