On Mar 31, 2009, at 12:08 PM, Tim Quinn wrote:
> 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.
I am not aware of that decision, did I make it ? (I have been known to
not remember past mistakes)
>
> 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