Long, long ago...
Bill Shannon wrote:
> Catching up on some old mail...
>
> Where did this end up? Are we now compatible by default? Did we add a
> deployment option to enable the old behavior?
This discussion died off in the spring, but the issue remains quite alive.
In fact, an issue filed today against the app client container is
directly due to this question:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=9068
I don't know of any work done in the meantime to address this. I'm
almost sure no new option or property has been added to the deploy
command so users could trigger the old behavior, nor am I aware of
changes to deployment to conform to the newly-specified, stricter
behavior.
To clarify one question in my mind: Is this an issue only with the app
client container, or are other containers affected also by the stricter
spec requirements?
As for moving forward on this, can we start by agreeing on a suitable
property name (and value) for the deploy command? I had used a really
lame one as an example in my mail from back in March which implied that
only the ACC was affected. Also, that name didn't reflect the v2
behavior in which EJB submodules were included in the downloaded app
client bits.
If we can agree on the property name and values then I can pretty
quickly revise the app client deployer accordingly.
For example, should it be something like
--property jarVisibility=javaee5
or
--property jarVisibility=v2
or
--property v2JarVisibility=true
or something else entirely?
- Tim
>
>
> Jerome Dochez wrote:
>> ok I see.
>> My take is that by default we should be spec compliant. I am fine
>> having a flag for backward compatibility, seems useful to me.
>>
>> jerome
>>
>> On Apr 1, 2009, at 3:06 AM, Kenneth Saks wrote:
>>
>>>
>>> On Mar 31, 2009, at 11:20 PM, Jerome Dochez wrote:
>>>
>>>>
>>>>>
>>>>> I just learned that a conscious decision was made that the
>>>>> server-side would not conform to this provision of the spec but
>>>>> would let modules see top-level JARs as in the past.
>>>> I am not aware of that decision, did I make it ? (I have been known
>>>> to not remember past mistakes)
>>>
>>> Yes, we discussed it with Hong about a month ago. The decision was
>>> to preserve the V2 behavior of making any .jars at the .ear level
>>> visible as library .jars. We only talked about the server-side case
>>> though, not app clients.
>>>
>>
>