On Aug 20, 2009, at 11:54 AM, Roberto Chinnici wrote:
> Tim Quinn wrote:
>> Roberto Chinnici wrote:
>>> I'm not sure why you think I'd prefer 2, or why you prefer 1.
>>>
>>> In 1, instead of having a bunch of class not found exceptions with
>>> no other explanation, you could detect that the problem is in the
>>> appclient, then see that the missing classes happen to be in
>>> certain jars and print a decent error message.
>> I don't follow how this would work.
>>
>> The exceptions you mention would occur at runtime. Under v3 a
>> client - and the ACC - would be running without any access to the
>> now-forbidden JARs. That is, not only would they not be on the
>> class path, the JARs would not be downloaded to the remote client
>> system.
>>
>> How do you envision the ACC deducing that a missing class is in
>> fact in one of the forbidden JARs - and how would it know which
>> one? I suppose deployment could construct an index of all the
>> packages in all the JARs in the EAR and send that in the download
>> of the cooked JAR so the ACC could consult it in case of a missing
>> class. I don't know how costly an operation that would prove to be
>> - and that cost would of course depend on the number and sizes of
>> the JARs in the EAR.
>>
>> Or did you have something else in mind?
>
> Jerome mentioned that the app would fail to redeploy, with confusing
> errors. Now it seems you're saying that it won't fail to redeploy,
> it'll only fail much later.
it actually depends, it could fail on redeploy or later at runtime,
depending how widely those missing jars are used throughout the
application.
>
> My thought was that, if we detected something strange at deployment
> time, we could go and look at the class files inside the application
> client jar in an ear, figure out what classes it references and then
> try to locate them. I don't think we would want to do something like
> that as a matter of routine when we run the application client.
> Scanning the app client classes at deployment in all cases seems
> like it might be expensive too, but perhaps it could be deferred to
> the first time the app client jar is requested?
this honestly seem quite convoluted to implement...
if you are not deterred with option 1 then I think we should just
carry on like this. This is the safest option for our users, and we
should print a Warning so next release we remote the flag and feature.
jerome
>
> --Roberto
>
>>
>> - Tim
>>>
>>> Of course, app clients that use reflection exclusively to access
>>> this kind of classes would not be handled so nicely. I sincerely
>>> hope there are no such app clients around.
>>>
>>> --Roberto
>>>
>>> Jerome Dochez wrote:
>>>> this does pose a number of significant compatibility issues. For
>>>> instance, take an upgrade scenario, where applications (using
>>>> that behavior) were deployed successfully will not be able to be
>>>> upgraded to V3 without requiring the usage of the flag.
>>>>
>>>> So we seem to be stuck between two equally bad choices :
>>>> 1. we don't run the upgrade redeployment with the flag and
>>>> applications that were not flagged as using a deprecated or
>>>> incorrect feature in V1/V2 will fail to be upgraded correctly.
>>>> 2. we run with the flag which mean that we automatically upgrade
>>>> and run the already deployed applications in an incompatible mode.
>>>>
>>>> Even in normal re-deployment scenarios, applications will fail to
>>>> redeploy with confusing errors (class not found exceptions most
>>>> likely) while they deployed without an itch in v2. We seem to be
>>>> breaking basic binary compatibility.
>>>>
>>>> To come back to upgrade, as a product owner, I prefer 1), spec
>>>> writers will prefer 2), users will be confused anyhow :)
>>>> votes ?
>>>>
>>>> jerome
>>>>
>>>> On Aug 18, 2009, at 11:47 AM, Bill Shannon wrote:
>>>>
>>>>> 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
>>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>