Hi Jerome,
you are right - the smoother the migration from v2 to v3 the better.
In addition violation warnings would be great.
In our case it was a bigger project, built with maven, what was
perfectly deployable to GF v2 but didn't work with GF v3. My customer
didn't knew about the switch...
thanks for your fast response!,
adam
On 29.10.2009, at 17:03, Jerome Dochez wrote:
>
> 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
>>
>
Consultant, Author, Speaker, Java Champion
Weblog: blog.adam-bien.com
press: press.adam-bien.com
eMail: abien_at_adam-bien.com
twitter: twitter.com/adambien
Mobile: 0049(0)170 280 3144
Author: 7 (Java SE/EE, SOA) Books, about 100 articles