Finally getting back to this thread, sorry for the delay...
Hong Zhang wrote:
>
>> yes compatibility or compatible is a good name.
>>
> Ok.
>
> 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?
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?
> 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.