Hi, June
> So is the plan to add "compatibility" as a property of the
> sun-application element in the sun-application.xml file? I assume
> this would have the same default and functionality as the
> "compatibility" property of the application element in domain.xml.
> Currently the sun-application element doesn't have an optional
> property subelement, but adding one wouldn't break backward
> compatibility. You may have to increment the sun-application DTD
> version though.
I haven't looked into the implementation details on this yet, but yes it
should have the same functionality as the command line property.
> Please let Dixie and me know what you plan to do so we can make sure
> it's doc'd properly.
Yes, I will definitely follow up with you guys on the doc update once I
have the details. I don't think any doc update is needed for domain.xml
(it's the same property persisted in domain.xml whether it's from
sun-application.xml or from command line). But we will need to update
the doc for sun-application.xml (the version of the dtd for this has
already been incremented in this release).
Thanks,
- Hong
>
> On 10/30/09 09:20 AM, Hong Zhang wrote:
>
>> Thanks for all the discussions!
>>
>> It seems the main concern that the earlier versions of the NB
>> packaging the application incorrectly is not much of an issue. The
>> problem only happens when the earlier versions of the NB was used
>> together with maven (maven ignores the manifest entry) which will
>> have far less impact.
>>
>> So my current plan is to keep the default behavior as it is, but make
>> additional changes to provide a way for autodeploy (and JSR88) to
>> specify this property. We certainly encourage the users to re-package
>> the application the spec defined way, but we are not forcing it
>> (that's why we have this property). And we will try to provide useful
>> warnings for the cases where we could detect such packaging.
>>
>> Thanks,
>>
>> - Hong
>>
>> Sahoo wrote:
>>
>>>
>>>
>>> Tim Quinn wrote:
>>>
>>>>> I still don't see how we can force users to package the app in one
>>>>> particular way.
>>>>
>>>>
>>>> I don't think anyone suggested that. If you're thinking about my
>>>> note to Vince earlier, I described an approach that's probably
>>>> better from a design and information hiding point of view. I did
>>>> not say we should impose that or any approach on users.
>>>
>>>
>>>
>>> I am not saying you suggested the packaging was wrong. I thought one
>>> of the reasons this whole thread was started was because v3 rejected
>>> deployment of such apps unless compatibility=v2 mode was not
>>> enabled. If that's not the case, I am confused why we raised NB
>>> packaging issue to start with.
>>>
>>> Sahoo
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>