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
>