Hi, June
> If you come up with what I assume would be an application element
> property for the deployment descriptor, please let the doc team know
> all the details, exact name, parent element, default, exact option
> name for asadmin deploy, etc.
This flag will be supported as a deployment property with name
"compatibility" (and it will be persisted as an application property in
the domain.xml like any other deployment property where its parent
element is the application element):
asadmin deploy --property compatibility=xxx foo.war
where the xxx indicates which release it wants to be backward compatible
with.
The default value for this property is null (and in which case, it will
not be written out in the domain.xml). The current supported non-null
value for this property is "v2".
When this property is set to "v2", the v2 compatibility including the
jar visibility which was discussed in this thread will be maintained.
- Hong
>
> On 08/19/09 03:17 PM, 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?
>>
>> - 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
>