Hong Zhang wrote on 08/31/09 07:10:
>
>>> 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.
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.
>>> 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.
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.