the v2 compatibility property

[Hong Zhang]

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@...
For additional commands, e-mail: dev-help@...

[Bill Shannon]

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?  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.

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@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ludovic Champenois]

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@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Sahoo]

Hong Zhang wrote:
> 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.
>
 From my limited experience of using NB to write ee apps, I thought NB
generates Class-Path reference for library jars. Can you ask for an
example application as packaged by earlier version of NB to see what is
the packaging issue.

Thanks,
Sahoo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Bill Shannon]

Ludovic Champenois wrote:

> 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...

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@...
For additional commands, e-mail: dev-help@...

[Hong Zhang]

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.

     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@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jerome Dochez]

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@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[vince kraemer]

On 10/28/09 23:46, Bill Shannon wrote:

> [snip]
> 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.

I do not think NetBeans has ever packaged "jar files in the root of the
ear file with the expectation that they will be available to all modules
in the ear file".

NetBeans has added Class-Path entries to the manifest of modules to
explicitly describe the references since NB 4.1, which shipped in May
2005. That is the method described in J2EE 8.2, "Optional Package
Support".  This method has also been described as part of the spec for
Java EE 5 and Java EE 6.

vbk

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Marina Vatkina]

Vince,

Would NB add the whole EJB jar to the client's jar manifest?

thanks,
-marina

Vince Kraemer wrote:

> On 10/28/09 23:46, Bill Shannon wrote:
>
>> [snip]
>> 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.
>
>
> I do not think NetBeans has ever packaged "jar files in the root of the
> ear file with the expectation that they will be available to all modules
> in the ear file".
>
> NetBeans has added Class-Path entries to the manifest of modules to
> explicitly describe the references since NB 4.1, which shipped in May
> 2005. That is the method described in J2EE 8.2, "Optional Package
> Support".  This method has also been described as part of the spec for
> Java EE 5 and Java EE 6.
>
> vbk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[vince kraemer]

I am unaware of any method to add 'part' of a jar to a Class-Path in the
MANIFEST.MF

vbk

Marina Vatkina wrote:

> Vince,
>
> Would NB add the whole EJB jar to the client's jar manifest?
>
> thanks,
> -marina
>
> Vince Kraemer wrote:
>> On 10/28/09 23:46, Bill Shannon wrote:
>>
>>> [snip]
>>> 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.
>>
>>
>> I do not think NetBeans has ever packaged "jar files in the root of
>> the ear file with the expectation that they will be available to all
>> modules in the ear file".
>>
>> NetBeans has added Class-Path entries to the manifest of modules to
>> explicitly describe the references since NB 4.1, which shipped in May
>> 2005. That is the method described in J2EE 8.2, "Optional Package
>> Support".  This method has also been described as part of the spec
>> for Java EE 5 and Java EE 6.
>>
>> vbk

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Marina Vatkina]

This causes this bug in v3:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=9579 :(

-marina

vince kraemer wrote:

> I am unaware of any method to add 'part' of a jar to a Class-Path in the
> MANIFEST.MF
>
> vbk
>
> Marina Vatkina wrote:
>
>> Vince,
>>
>> Would NB add the whole EJB jar to the client's jar manifest?
>>
>> thanks,
>> -marina
>>
>> Vince Kraemer wrote:
>>
>>> On 10/28/09 23:46, Bill Shannon wrote:
>>>
>>>> [snip]
>>>> 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.
>>>
>>>
>>>
>>> I do not think NetBeans has ever packaged "jar files in the root of
>>> the ear file with the expectation that they will be available to all
>>> modules in the ear file".
>>>
>>> NetBeans has added Class-Path entries to the manifest of modules to
>>> explicitly describe the references since NB 4.1, which shipped in May
>>> 2005. That is the method described in J2EE 8.2, "Optional Package
>>> Support".  This method has also been described as part of the spec
>>> for Java EE 5 and Java EE 6.
>>>
>>> vbk
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Tim Quinn]

A bit of clarification...

I think Vince was reacting to the earlier reference to adding the
"whole" EJB JAR to the client's Class-Path, saying that there's no known
way to add a "part" of a JAR to a Class-Path so it's either all or
nothing when it comes to adding library JARs.

Restating Marina's question, from my perspective at last, would be this:

    Would NB automatically add the EJB module JAR to the client's
Class-Path?

Vince, the underlying point in the issue Marina pointed to is that a
sample app has the app client JAR referring directly to an EJB module.  
In general, this technique gives a client visibility to the EJB
interface(s), which is all it should really need, but it also lets the
client see classes it should not see: the EJB implementation classes for
one thing.  In particular, there is annotation processing that involves
the client and which must include JARs which the client references.  In
this example there are annos in the EJB module which make no sense in
the client environment and that triggers log messages during anno
processing.

The better design we typically encourage is to collect the EJB interface
and any other shared bits into a library JAR on which both the client
and the EJB module can depend.  

The main point of the question directed your way was to find out whether
NB automatically adds the EJB module to the client's Class-Path, for
example, if the developer adds annotated references to EJB.


Thanks.

- Tim

Marina Vatkina wrote:

> This causes this bug in v3:
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=9579 :(
>
> -marina
>
> vince kraemer wrote:
>> I am unaware of any method to add 'part' of a jar to a Class-Path in
>> the MANIFEST.MF
>>
>> vbk
>>
>> Marina Vatkina wrote:
>>
>>> Vince,
>>>
>>> Would NB add the whole EJB jar to the client's jar manifest?
>>>
>>> thanks,
>>> -marina
>>>
>>> Vince Kraemer wrote:
>>>
>>>> On 10/28/09 23:46, Bill Shannon wrote:
>>>>
>>>>> [snip]
>>>>> 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.
>>>>
>>>>
>>>>
>>>> I do not think NetBeans has ever packaged "jar files in the root of
>>>> the ear file with the expectation that they will be available to
>>>> all modules in the ear file".
>>>>
>>>> NetBeans has added Class-Path entries to the manifest of modules to
>>>> explicitly describe the references since NB 4.1, which shipped in
>>>> May 2005. That is the method described in J2EE 8.2, "Optional
>>>> Package Support".  This method has also been described as part of
>>>> the spec for Java EE 5 and Java EE 6.
>>>>
>>>> vbk
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[vince kraemer]

On 10/29/09 14:09, Tim Quinn wrote:

> A bit of clarification...
>
> I think Vince was reacting to the earlier reference to adding the
> "whole" EJB JAR to the client's Class-Path, saying that there's no
> known way to add a "part" of a JAR to a Class-Path so it's either all
> or nothing when it comes to adding library JARs.
>
> Restating Marina's question, from my perspective at last, would be this:
>
>    Would NB automatically add the EJB module JAR to the client's
> Class-Path?

Yes. NetBeans did do that until recently.  It has done that for about 4
years. This is the first time that this issue has been raised.

Note: NB has also supported other J2EE and Java EE servers over that
time... and the J2EE and Java EE developers that target those servers
have not complained of difficulties in this area.

>
> Vince, the underlying point in the issue Marina pointed to is that a
> sample app has the app client JAR referring directly to an EJB
> module.  In general, this technique gives a client visibility to the
> EJB interface(s), which is all it should really need, but it also lets
> the client see classes it should not see: the EJB implementation
> classes for one thing.  In particular, there is annotation processing
> that involves the client and which must include JARs which the client
> references.  In this example there are annos in the EJB module which
> make no sense in the client environment and that triggers log messages
> during anno processing. The better design we typically encourage is to
> collect the EJB interface and any other shared bits into a library JAR
> on which both the client and the EJB module can depend.

OK.  It seems like more work for very little payoff. I am not sure
developers will like restructuring their apps to create a three jars for
two logical modules...  even if an IDE does it for them.

> The main point of the question directed your way was to find out
> whether NB automatically adds the EJB module to the client's
> Class-Path, for example, if the developer adds annotated references to
> EJB.
>
>
> Thanks.
>
> - Tim
>
> Marina Vatkina wrote:
>> This causes this bug in v3:
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=9579 :(
>>
>> -marina
>>
>> vince kraemer wrote:
>>> I am unaware of any method to add 'part' of a jar to a Class-Path in
>>> the MANIFEST.MF
>>>
>>> vbk
>>>
>>> Marina Vatkina wrote:
>>>
>>>> Vince,
>>>>
>>>> Would NB add the whole EJB jar to the client's jar manifest?
>>>>
>>>> thanks,
>>>> -marina
>>>>
>>>> Vince Kraemer wrote:
>>>>
>>>>> On 10/28/09 23:46, Bill Shannon wrote:
>>>>>
>>>>>> [snip]
>>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>> I do not think NetBeans has ever packaged "jar files in the root
>>>>> of the ear file with the expectation that they will be available
>>>>> to all modules in the ear file".
>>>>>
>>>>> NetBeans has added Class-Path entries to the manifest of modules
>>>>> to explicitly describe the references since NB 4.1, which shipped
>>>>> in May 2005. That is the method described in J2EE 8.2, "Optional
>>>>> Package Support".  This method has also been described as part of
>>>>> the spec for Java EE 5 and Java EE 6.
>>>>>
>>>>> vbk

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Sahoo]

Tim,

Why is the annotation processor of ACC even looking for EJB annotations
and then logging messages when it finds them?

Sahoo

Tim Quinn wrote:

> A bit of clarification...
>
> I think Vince was reacting to the earlier reference to adding the
> "whole" EJB JAR to the client's Class-Path, saying that there's no
> known way to add a "part" of a JAR to a Class-Path so it's either all
> or nothing when it comes to adding library JARs.
>
> Restating Marina's question, from my perspective at last, would be this:
>
>    Would NB automatically add the EJB module JAR to the client's
> Class-Path?
>
> Vince, the underlying point in the issue Marina pointed to is that a
> sample app has the app client JAR referring directly to an EJB
> module.  In general, this technique gives a client visibility to the
> EJB interface(s), which is all it should really need, but it also lets
> the client see classes it should not see: the EJB implementation
> classes for one thing.  In particular, there is annotation processing
> that involves the client and which must include JARs which the client
> references.  In this example there are annos in the EJB module which
> make no sense in the client environment and that triggers log messages
> during anno processing.
> The better design we typically encourage is to collect the EJB
> interface and any other shared bits into a library JAR on which both
> the client and the EJB module can depend.
> The main point of the question directed your way was to find out
> whether NB automatically adds the EJB module to the client's
> Class-Path, for example, if the developer adds annotated references to
> EJB.
>
>
> Thanks.
>
> - Tim
>
> Marina Vatkina wrote:
>> This causes this bug in v3:
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=9579 :(
>>
>> -marina
>>
>> vince kraemer wrote:
>>> I am unaware of any method to add 'part' of a jar to a Class-Path in
>>> the MANIFEST.MF
>>>
>>> vbk
>>>
>>> Marina Vatkina wrote:
>>>
>>>> Vince,
>>>>
>>>> Would NB add the whole EJB jar to the client's jar manifest?
>>>>
>>>> thanks,
>>>> -marina
>>>>
>>>> Vince Kraemer wrote:
>>>>
>>>>> On 10/28/09 23:46, Bill Shannon wrote:
>>>>>
>>>>>> [snip]
>>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>> I do not think NetBeans has ever packaged "jar files in the root
>>>>> of the ear file with the expectation that they will be available
>>>>> to all modules in the ear file".
>>>>>
>>>>> NetBeans has added Class-Path entries to the manifest of modules
>>>>> to explicitly describe the references since NB 4.1, which shipped
>>>>> in May 2005. That is the method described in J2EE 8.2, "Optional
>>>>> Package Support".  This method has also been described as part of
>>>>> the spec for Java EE 5 and Java EE 6.
>>>>>
>>>>> vbk
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Marina Vatkina]

Sahoo,

The problem is that it's correct to complain if @PersistenceContext in the Main
class, and we shouldn't log this at fine level, but somehow skip processing of
the classes that we are not suppose to be processing at that time (like @Stateless).

Regards,
-marina

Sahoo wrote:

> Tim,
>
> Why is the annotation processor of ACC even looking for EJB annotations
> and then logging messages when it finds them?
>
> Sahoo
>
> Tim Quinn wrote:
>
>> A bit of clarification...
>>
>> I think Vince was reacting to the earlier reference to adding the
>> "whole" EJB JAR to the client's Class-Path, saying that there's no
>> known way to add a "part" of a JAR to a Class-Path so it's either all
>> or nothing when it comes to adding library JARs.
>>
>> Restating Marina's question, from my perspective at last, would be this:
>>
>>    Would NB automatically add the EJB module JAR to the client's
>> Class-Path?
>>
>> Vince, the underlying point in the issue Marina pointed to is that a
>> sample app has the app client JAR referring directly to an EJB
>> module.  In general, this technique gives a client visibility to the
>> EJB interface(s), which is all it should really need, but it also lets
>> the client see classes it should not see: the EJB implementation
>> classes for one thing.  In particular, there is annotation processing
>> that involves the client and which must include JARs which the client
>> references.  In this example there are annos in the EJB module which
>> make no sense in the client environment and that triggers log messages
>> during anno processing.
>> The better design we typically encourage is to collect the EJB
>> interface and any other shared bits into a library JAR on which both
>> the client and the EJB module can depend. The main point of the
>> question directed your way was to find out whether NB automatically
>> adds the EJB module to the client's Class-Path, for example, if the
>> developer adds annotated references to EJB.
>>
>>
>> Thanks.
>>
>> - Tim
>>
>> Marina Vatkina wrote:
>>
>>> This causes this bug in v3:
>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=9579 :(
>>>
>>> -marina
>>>
>>> vince kraemer wrote:
>>>
>>>> I am unaware of any method to add 'part' of a jar to a Class-Path in
>>>> the MANIFEST.MF
>>>>
>>>> vbk
>>>>
>>>> Marina Vatkina wrote:
>>>>
>>>>> Vince,
>>>>>
>>>>> Would NB add the whole EJB jar to the client's jar manifest?
>>>>>
>>>>> thanks,
>>>>> -marina
>>>>>
>>>>> Vince Kraemer wrote:
>>>>>
>>>>>> On 10/28/09 23:46, Bill Shannon wrote:
>>>>>>
>>>>>>> [snip]
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I do not think NetBeans has ever packaged "jar files in the root
>>>>>> of the ear file with the expectation that they will be available
>>>>>> to all modules in the ear file".
>>>>>>
>>>>>> NetBeans has added Class-Path entries to the manifest of modules
>>>>>> to explicitly describe the references since NB 4.1, which shipped
>>>>>> in May 2005. That is the method described in J2EE 8.2, "Optional
>>>>>> Package Support".  This method has also been described as part of
>>>>>> the spec for Java EE 5 and Java EE 6.
>>>>>>
>>>>>> vbk
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Sahoo]

Surely ACC can install appropriate annotation handlers to override the
behavior of annotation handlers used in server, can't it? I still don't
see how we can force users to package the app in one particular way.

Sahoo

Marina Vatkina wrote:

> Sahoo,
>
> The problem is that it's correct to complain if @PersistenceContext in
> the Main class, and we shouldn't log this at fine level, but somehow
> skip processing of the classes that we are not suppose to be
> processing at that time (like @Stateless).
>
> Regards,
> -marina
>
> Sahoo wrote:
>> Tim,
>>
>> Why is the annotation processor of ACC even looking for EJB
>> annotations and then logging messages when it finds them?
>>
>> Sahoo
>>
>> Tim Quinn wrote:
>>
>>> A bit of clarification...
>>>
>>> I think Vince was reacting to the earlier reference to adding the
>>> "whole" EJB JAR to the client's Class-Path, saying that there's no
>>> known way to add a "part" of a JAR to a Class-Path so it's either
>>> all or nothing when it comes to adding library JARs.
>>>
>>> Restating Marina's question, from my perspective at last, would be
>>> this:
>>>
>>>    Would NB automatically add the EJB module JAR to the client's
>>> Class-Path?
>>>
>>> Vince, the underlying point in the issue Marina pointed to is that a
>>> sample app has the app client JAR referring directly to an EJB
>>> module.  In general, this technique gives a client visibility to the
>>> EJB interface(s), which is all it should really need, but it also
>>> lets the client see classes it should not see: the EJB
>>> implementation classes for one thing.  In particular, there is
>>> annotation processing that involves the client and which must
>>> include JARs which the client references.  In this example there are
>>> annos in the EJB module which make no sense in the client
>>> environment and that triggers log messages during anno processing.
>>> The better design we typically encourage is to collect the EJB
>>> interface and any other shared bits into a library JAR on which both
>>> the client and the EJB module can depend. The main point of the
>>> question directed your way was to find out whether NB automatically
>>> adds the EJB module to the client's Class-Path, for example, if the
>>> developer adds annotated references to EJB.
>>>
>>>
>>> Thanks.
>>>
>>> - Tim
>>>
>>> Marina Vatkina wrote:
>>>
>>>> This causes this bug in v3:
>>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=9579 :(
>>>>
>>>> -marina
>>>>
>>>> vince kraemer wrote:
>>>>
>>>>> I am unaware of any method to add 'part' of a jar to a Class-Path
>>>>> in the MANIFEST.MF
>>>>>
>>>>> vbk
>>>>>
>>>>> Marina Vatkina wrote:
>>>>>
>>>>>> Vince,
>>>>>>
>>>>>> Would NB add the whole EJB jar to the client's jar manifest?
>>>>>>
>>>>>> thanks,
>>>>>> -marina
>>>>>>
>>>>>> Vince Kraemer wrote:
>>>>>>
>>>>>>> On 10/28/09 23:46, Bill Shannon wrote:
>>>>>>>
>>>>>>>> [snip]
>>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I do not think NetBeans has ever packaged "jar files in the root
>>>>>>> of the ear file with the expectation that they will be available
>>>>>>> to all modules in the ear file".
>>>>>>>
>>>>>>> NetBeans has added Class-Path entries to the manifest of modules
>>>>>>> to explicitly describe the references since NB 4.1, which
>>>>>>> shipped in May 2005. That is the method described in J2EE 8.2,
>>>>>>> "Optional Package Support".  This method has also been described
>>>>>>> as part of the spec for Java EE 5 and Java EE 6.
>>>>>>>
>>>>>>> vbk
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>>> For additional commands, e-mail: dev-help@...
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Tim Quinn]

Sahoo wrote:
> Surely ACC can install appropriate annotation handlers to override the
> behavior of annotation handlers used in server, can't it?
The issue is not about on anno handling in the ACC; the issue regards
anno handling during deployment although some of the same questions can
arise with anno handling in the ACC.

If you look at the code you'll see that the implemented handlers are
already sensitive to the context in which the scanning occurs - for
instance, whether the scanning starts from an app client module vs. an
EJB module vs. something else.  I think part of the problem is that the
scanners do not seem to distinguish between processing the original
module from processing JARs referenced by the module's Class-Path or
JARs in the EAR's library directory (or the transitive closure of those).

I think there is broad agreement that it's not working the way we want;
it's a question of deciding the best way to repair it.
> 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.


- Tim

>
> Sahoo
>
> Marina Vatkina wrote:
>> Sahoo,
>>
>> The problem is that it's correct to complain if @PersistenceContext
>> in the Main class, and we shouldn't log this at fine level, but
>> somehow skip processing of the classes that we are not suppose to be
>> processing at that time (like @Stateless).
>>
>> Regards,
>> -marina
>>
>> Sahoo wrote:
>>> Tim,
>>>
>>> Why is the annotation processor of ACC even looking for EJB
>>> annotations and then logging messages when it finds them?
>>>
>>> Sahoo
>>>
>>> Tim Quinn wrote:
>>>
>>>> A bit of clarification...
>>>>
>>>> I think Vince was reacting to the earlier reference to adding the
>>>> "whole" EJB JAR to the client's Class-Path, saying that there's no
>>>> known way to add a "part" of a JAR to a Class-Path so it's either
>>>> all or nothing when it comes to adding library JARs.
>>>>
>>>> Restating Marina's question, from my perspective at last, would be
>>>> this:
>>>>
>>>>    Would NB automatically add the EJB module JAR to the client's
>>>> Class-Path?
>>>>
>>>> Vince, the underlying point in the issue Marina pointed to is that
>>>> a sample app has the app client JAR referring directly to an EJB
>>>> module.  In general, this technique gives a client visibility to
>>>> the EJB interface(s), which is all it should really need, but it
>>>> also lets the client see classes it should not see: the EJB
>>>> implementation classes for one thing.  In particular, there is
>>>> annotation processing that involves the client and which must
>>>> include JARs which the client references.  In this example there
>>>> are annos in the EJB module which make no sense in the client
>>>> environment and that triggers log messages during anno processing.
>>>> The better design we typically encourage is to collect the EJB
>>>> interface and any other shared bits into a library JAR on which
>>>> both the client and the EJB module can depend. The main point of
>>>> the question directed your way was to find out whether NB
>>>> automatically adds the EJB module to the client's Class-Path, for
>>>> example, if the developer adds annotated references to EJB.
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> - Tim
>>>>
>>>> Marina Vatkina wrote:
>>>>
>>>>> This causes this bug in v3:
>>>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=9579 :(
>>>>>
>>>>> -marina
>>>>>
>>>>> vince kraemer wrote:
>>>>>
>>>>>> I am unaware of any method to add 'part' of a jar to a Class-Path
>>>>>> in the MANIFEST.MF
>>>>>>
>>>>>> vbk
>>>>>>
>>>>>> Marina Vatkina wrote:
>>>>>>
>>>>>>> Vince,
>>>>>>>
>>>>>>> Would NB add the whole EJB jar to the client's jar manifest?
>>>>>>>
>>>>>>> thanks,
>>>>>>> -marina
>>>>>>>
>>>>>>> Vince Kraemer wrote:
>>>>>>>
>>>>>>>> On 10/28/09 23:46, Bill Shannon wrote:
>>>>>>>>
>>>>>>>>> [snip]
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I do not think NetBeans has ever packaged "jar files in the
>>>>>>>> root of the ear file with the expectation that they will be
>>>>>>>> available to all modules in the ear file".
>>>>>>>>
>>>>>>>> NetBeans has added Class-Path entries to the manifest of
>>>>>>>> modules to explicitly describe the references since NB 4.1,
>>>>>>>> which shipped in May 2005. That is the method described in J2EE
>>>>>>>> 8.2, "Optional Package Support".  This method has also been
>>>>>>>> described as part of the spec for Java EE 5 and Java EE 6.
>>>>>>>>
>>>>>>>> vbk
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>>>> For additional commands, e-mail: dev-help@...
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>>> For additional commands, e-mail: dev-help@...
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Sahoo]

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@...
For additional commands, e-mail: dev-help@...

[Hong Zhang]

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@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[June.Parks]

Hi Hong,

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.

Please let Dixie and me know what you plan to do so we can make sure
it's doc'd properly.

June

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@...
>> For additional commands, e-mail: dev-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...