On Oct 29, 2009, at 6:55 AM, Hong Zhang wrote:
> Hi, Bill
> I am adding Adam who reported the issue to provide more details
> on the incorrect NetBeans packaging.
>
> Yes, adding this property through the sun-application.xml should
> be doable for this release. I was more interested to hear people's
> thoughts on what should be the default behavior for v3.
right, I think that adding the sun-application.xml flag is progress
but might still be unacceptable for users who saw their applications
deploying correctly in v2 but suddenly fail in v3. This is
specifically bad if those were built with netbeans.
IIRC, this is a spec requirement of the Java EE platform spec, so
short of changing that spec requirement, I am not sure how much
leverage we have in changing the default behavior,
jerome
>
> Thanks,
>
> - Hong
>
>>>> A way to set the property in sun-application.xml is reasonable.
>>>> Can't any deployment time property be set there?
>>>>
>>>> Can anyone provide more information on what situations NetBeans
>>>> would
>>>> package an app incorrectly?
>>> Not sure...
>>>> I'd especially like to hear from the
>>>> NetBeans developer who implemented this feature to understand why
>>>> he thought he should do it that way.
>>> Bill, so far Nb uses an extended JSR 88 style deployment...Having
>>> all the new props we have today in cli mode (which is not JSR 88
>>> style) would be very nice to have. This way, the developer could
>>> change a sun-web.xml and or a sun-application.xml to add Galssfish
>>> Specific deployment properties. This way, this would be from the
>>> Nb side a server agnostic feature: just edit the Sun* files, and
>>> do not provide more GUI for specific properties.
>>> I asked for that a long time ago, and time/resource constraints
>>> have other priorities.
>>> There is no way so far that Nb would expose this new
>>> "compatibility" property unless we change UI post UI freeze, a
>>> usal no-no.
>>> Changing sun-web.xml dtd is also way too late...
>>
>> My understanding was that the issue we're talking about only effects
>> ear files. As I said above, I agree that having a way to set this
>> property in the sun-application.xml file would be good.
>>
>> But I'm still interested in the details of when NetBeans packages jar
>> files in the root of the ear file with the expectation that they'll
>> be available to all modules in the ear file, and why the NetBeans
>> developer who implemented it that way thought that was a good thing
>> to do.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>