>> 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.
> 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.
>> 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.
Thanks,
- Hong