> 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):
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.
For individual deployer (such as JPADeployer and AppClientDeployer) to
implement their part of the backward compatibility support, access the
property through DeploymentContext:
deploymentContext.getAppProps().getProperty(DeploymentProperties.COMPATIBILITY)
- Hong
> On Aug 24, 2009, at 8:20 AM, Hong Zhang wrote:
>
>> Have we decided on the flag name for this? As the purpose of the
>> flag in this case is mainly maintaining backward compatibility with
>> prior releases, I think it makes sense to use a more generic flag
>> like "compatibility" as Sahoo suggested so we can use the same flag
>> for other compatibility related things...
>>
>>
>>> Finally, on a second thought, I think we can rename the deploy
>>> option from "jarVisibility" to something like "compatibility" so
>>> that we can use the same flag any other compatibility issues. Then,
>>> we don't need yet another option when move to next version. We can
>>> just have --compatibility=v3 while running in v3++.
>>
>>
>>
>>
>> Jerome Dochez wrote:
>>
>>>
>>> On Aug 21, 2009, at 2:11 PM, Roberto Chinnici wrote:
>>>
>>>> Jerome Dochez wrote:
>>>>
>>>>>
>>>>> On Aug 21, 2009, at 10:07 AM, Sahoo wrote:
>>>>>
>>>>>> Jerome Dochez wrote:
>>>>>>
>>>>>>>
>>>>>>> if you are not deterred with option 1 then I think we should
>>>>>>> just carry on like this. This is the safest option for our
>>>>>>> users, and we should print a Warning so next release we remote
>>>>>>> the flag and feature.
>>>>>>
>>>>>>
>>>>>> Jerome,
>>>>>>
>>>>>> Did you mean option 1 or 2? Unless I am missing something,
>>>>>> option #1 can lead to broken applications after upgrade. Is it
>>>>>> safer than option #2?
>>>>>>
>>>>> yes of course, I meant using the flag.
>>>>
>>>>
>>>>
>>>> So this only applies to applications already deployed when we
>>>> upgrade, and for all other apps, we follow EE 6 by default and if
>>>> your app breaks you need to specify the flag?
>>>
>>>
>>> yes.
>>>
>>>> I'd be OK with that, I guess, but what makes you think you'll
>>>> ever be able to remove the flag?
>>>> That would imply that one day an app that ran on v2 (by default)
>>>> and on v3 (with the flag) will absolutely not run unmodified on v4.
>>>
>>>
>>> that's correct if we choose to remove the flag, but at least the
>>> upgrade from v2 to v3 gave a warning to the user.
>>>
>>>>
>>>> --Roberto
>>>>
>>>>> thanks for catching this.
>>>>>
>>>>> Jerome
>>>>>
>>>>>> By 1 & 2, I mean the following (taken from your earlier email):
>>>>>> /1. we don't run the upgrade redeployment with the flag and
>>>>>> applications that were not flagged as using a deprecated or
>>>>>> incorrect feature in V1/V2 will fail to be upgraded correctly.
>>>>>> 2. we run with the flag which mean that we automatically
>>>>>> upgrade and run the already deployed applications in an
>>>>>> incompatible mode.
>>>>>> /
>>>>>> Thanks,
>>>>>> Sahoo
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>