Hi, Bill
>>>> This flag will be supported as a deployment property (and it will
>>>> be persisted as a property in the domain.xml like any other
>>>> deployment property):
>>>
>>>
>>>
>>> It will be retained on redeploy but lost on undeploy/deploy, right?
>>
>>
>> No, it's not retained on redeploy currently.
>> What happens if user wants to redeploy an application after fixing
>> the application to follow EE5+ spec for jar visibility? In that case,
>> we don't want to retain the flag?
>> But I can see retaining the flag could be useful for the cases where
>> an application relying on v2 behavior was upgraded from an old
>> domain, and suddenly it stopped working after being redeployed with
>> some minor changes.
>> I can implement either way depending on what people agree on.
>
>
> Ya, that's the case I was worried about. I'd like to know what others
> think as well.
As no one else has any comments on this, I will make the changes to
retain the flag for redeploy.
> Either way I think we need to notify the user that there's a potential
> issue with the application, which is why I want to only apply the flag
> in cases where there might be such an issue.
>
>>> Will it be displayed in the GUI, perhaps with a warning to "fix"
>>> the app, and a link to what in the app might need to be fixed?
>>
>>
>> As it will be difficult to detect whether an application really
>> relies on the v2 behavior and figure out what in the app needs to be
>> fixed, I don't know how useful it will be to display this in the GUI.
>
>
> Without it, users are going to be surprised when things stop working.
Anissa: can you display a warning in the GUI if the flag is set for a
particular application (you can find this information from config bean,
just like how we get the value of the isComposite property)? We can ask
the doc team to provide some documentation on this which the warning can
link to (I think we can probably just use the paragraph that's written
for this flag in the deploy man page). We can talk about the details
offline.
>
>>>> asadmin deploy --property compatibility=xxx foo.war
>>>>
>>>> where the xxx indicates which release it wants to be backward
>>>> compatible with. The v2 jar visibility will be maintained when xxx
>>>> is set to v2.
>>>>
>>>> I have made the changes to include root level libraries in the
>>>> classpath for ear case when this property is set to v2 (this was
>>>> the behavior in v2). I have also made the changes to set this
>>>> property to v2 in the v2->v3 upgrade process.
>>>
>>>
>>>
>>> I was hoping that we would only need to set this flag in cases where
>>> it *might* make a difference. Can we figure that out easily? For
>>> example,
>>> if there are *no* jar files in the root directory of an ear (does that
>>> ever happen?), we would not need this flag. Or perhaps if there are no
>>> root level jars that are not modules, and there are no app clients? I
>>> guess I'm not clear on exactly what it is that people have been
>>> depending
>>> on here.
>>
>>
>> It is difficult to detect accurately if an application is relying on
>> the old v2 jar visibility or not. Having jars at root level does not
>> necessarily mean the application reference those jars or reference
>> those jars using the v2 jar visibility behavior.
>> We can detect the obvious cases that you described (where there is no
>> root level non-module jars), and not use the flag in those cases. But
>> in those cases, the classpath is the same whether we set the flag or
>> not as there is no root level non-modules jars to add to the
>> classpath anyways.
>
>
> Right, so there's one case we don't have to warn people. If we can
> detect
> a few more simple cases where we don't have to warn people, I think it
> will be an improvement.
Ok, I will make the changes to detect this simplest case for now. We
can further improve it if we have more time to spend on it.
> If the warning includes a link to the documentation of the issue, at
> least
> people will have an obvious path to finding out about the problem and
> fixing their app to avoid it.
Yes, make sense.
Thanks,
- Hong