I would think that the new option takes precedence if specified.
-marina
Shing Wai Chan wrote:
> I also feel that it is confusing to user if we allow to keep state for
> only one component.
>
> In web, we already have --property keepSessions=true to keep the state
> for redeployment.
> If we decide to use --keepState, then what will we do with the
> --property keepSessions?
> Will we deprecate the former one? (Do we really want to change to option?)
> If we allow both, then which one will take the precedence? (This may be
> confusing to user.)
>
> Shing Wai Chan
>
>
> On 6/9/10 1:57 PM, Mahesh Kannan wrote:
>
>> The problem with keepState=web,ejb is:
>> 1. Why would a user want to retain just web state and not ejb state
>> (or vice versa) in his application?
>> 2. If ejb container is NOT ha enabled, what will be the effect of
>> specifying --keepState=web,ejb ?
>>
>> I prefer to say --keepState=true and let each container to retain
>> whatever "state" means to them.
>>
>> --Mahesh
>>
>> On 06/09/2010 01:00 PM, Marina Vatkina wrote:
>>
>>> Tim,
>>>
>>> I like this idea. But I'm not sure I understand the end result -
>>> would we support both, --keepState=web,ejb *and*
>>> --property=keepXXX=true (for all XXX)?
>>>
>>> thanks,
>>> -marina
>>>
>>> Tim Quinn wrote:
>>>
>>>> A couple things.
>>>>
>>>> 1. Note that the current keepSessions feature is specified as a
>>>> property on the redeploy command, such as
>>>>
>>>> asadmin redeploy ... --property=keepSessions=true
>>>>
>>>> not as its own option.
>>>> 2. Now that multiple containers will support this type of behavior,
>>>> it might be more intuitive for users to have a new option (not a
>>>> property, an option)
>>>>
>>>> --keepState
>>>>
>>>> which can accept one or more values identifying the container types
>>>> to enlist in the state-keeping behavior. For example:
>>>> asadmin redeploy ... --keepState=web,ejb
>>>>
>>>> would cause both containers to maintain whatever "state" means to
>>>> them. Thus
>>>>
>>>> ... --property=keepSessions=true
>>>>
>>>> and
>>>>
>>>> ... --keepState=web
>>>>
>>>> would be equivalent.
>>>>
>>>> - Tim
>>>>
>>>> On Jun 9, 2010, at 1:15 PM, Marina Vatkina wrote:
>>>>
>>>>> Bill, Arch team,
>>>>>
>>>>> EJB enhancement for GlassFish 3.1 proposes support for retaining
>>>>> SFSB / EJB Timer state across redeployment (see section 4.1.5 in
>>>>> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishv3.1EJBOnePager)
>>>>> <http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishv3.1EJBOnePager%29>.
>>>>>
>>>>>
>>>>> The original proposal was to add a new CLI option to 'asadmin
>>>>> redeploy' for this purpose called 'keepEjbState' in addtion to the
>>>>> existing 'keepSession' option.
>>>>>
>>>>> While having two separate options clearly identifies the intent of
>>>>> the operation, it can be confusing to the user who has both, a web
>>>>> component and an ejb component in their application (in particular
>>>>> with Java EE 6 allowing to combine both in a single WAR). On the
>>>>> other hand, eusing 'keepSession' option for both purposes can be
>>>>> confusing for applications that do not have a web component.
>>>>>
>>>>> One more question: would it make sense to rename 'keepEjbState' to
>>>>> 'keepState' for future (non-EJB) extensions? If yes, would it be
>>>>> even more confusing to have both options around?
>>>>>
>>>>> Here are the choices that we are looking at:
>>>>> 1. Add 'keepEjbState' in addtion to 'keepSession'
>>>>> 2a. Add 'keepState' in addtion to 'keepSession'
>>>>> 2b. Deprecate 'keepSession', and use 'keepState' instead
>>>>> 3. Reuse 'keepSession' for any 'keep' option.
>>>>>
>>>>> Please advice.
>>>>>
>>>>> thanks,
>>>>> -marina
>>>>
>>>>
>>>>
>>>>
>>>> Oracle <http://www.oracle.com>
>>>> Tim Quinn | Principal Member of Technical Staff | +1.847.604.9475
>>>> Oracle GlassFish Engineering
>>>> Lake Forest, IL
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>