Bill Shannon wrote:
> 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...
Ludo
>
> Hong Zhang wrote:
>> Hi,
>> I'd like to collect further feedback on the "compatibility"
>> property that was added in v3. We had some previous discussions on
>> this, here is a quick summary to help people refresh their memory:
>> 1. The EE 5 spec started to define the packaging of the bundled
>> libraries of a Java EE application. The bundled libraries should be
>> placed in the library directory of the application (the directory
>> could be defined through application.xml and its default is lib).
>> 2. In v2 we continued supporting the cases where the libraries are
>> placed at the application root in addition to the EE spec defined
>> packaging.
>> 3. In EE 6 spec, it further clarified the visibility of the classes.
>> 3. In v3, we decided to clean this part up and only support the
>> spec defined packaging (we were thinking if we don't do this clean up
>> now, we probably will never be able to do it).
>> 4. We introduced the compatibility property to support v2 backward
>> compatibility (when the property is set, we have the same jar
>> visibility as in v2).
>>
>> Since this part was implemented, a few cases were reported that an
>> application which used to run ok in v2 now stopped working in v3. So
>> we told them about the property and they went away. :-)
>>
>> Now, for the latest reported case, the reporter raised a good
>> point that you cannot really pass in a property for the autodeploy
>> (which is also true for JSR88 case). So we need to be able to define
>> this property in domain.xml as a global setting and/or define this
>> property in sun-application.xml as a local setting. And furthermore
>> the reporter suggested the default behavior should be "v2 compatible"
>> and the property should be used for "spec defined way" (of course no
>> one will ever use this property now!). He mentioned the earlier
>> versions of the NetBeans (<6.8) packages the application in the spec
>> incompatible way so we might see quite a few cases of v2 app not
>> working in v3.
>>
>> This is the relevant glassfish issue and the reporter's blog:
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=10496
>> http://www.adam-bien.com/roller/abien/entry/is_glassfish_v3_ready_for#comment-1256745799671
>>
>>
>> What are people's thoughts on this? Should we go back to the old v2
>> behavior by default? Or as we already provided a path for user to
>> deploy the app in a v2 compatible way, we should just leave it like
>> that (with additional changes to provide a way to specify this
>> property for autodeploy/JSR88 path)?
>>
>> Thanks,
>>
>> - Hong
>>
>> ---------------------------------------------------------------------
>> 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
>