Hi, Shingwai
> Just want a clarification.
> 1. How do I know whether the --keepstate is in command line or not?
If the --keepstate has the tri-state values, null/false/true, the null
will mean it's not specified by the user in the command line.
> 2. if both --keepstate and --property keepSessions=<true|false> are
> applied, then should the --keepstate take precedence?
I think the keepSessions should have higher precedence. The keepSessions
was introduced earlier, so this will make sure no behavior change for
users who use the keepSessions property. Also the keepSessions is a web
specific configuration, and usually specific configuration should
override the more general configuration.
Thanks,
- Hong
>
> On 6/28/10 6:06 PM, Hong Zhang wrote:
>> Hi, Bill
>>>> I want to follow up on this thread to make sure everyone is on the
>>>> same
>>>> page before starting to implement this.
>>>>
>>>> 1. We will add keepState as a command line option with a single
>>>> boolean
>>>> value (applies to all module types).
>>> For consistency with other command line options, it should be
>>> documented
>>> as "--keepstate" (all lower case).
>> Yes, good point. Will do.
>>>> 2. What should be the default value of this keepState option? False or
>>>> null? Shingwai had the concern that if the default value is false, the
>>>> container will not know if it's explicitly set to false by the user or
>>>> it's the default value. Any thoughts on this? Any potential issue of
>>>> having this option default value as null?
>>> I'm a little nervous about assuming that these boolean options are
>>> actually tri-state values - null/false/true. But, I believed we've
>>> used this elsewhere, and it does solve the problem of allowing the
>>> CLI to override the deployment descriptor if the option is specified
>>> explicitly.
>>>
>>>> 3. The support for autodeploy/JSR88. In the asarch review of the
>>>> deployment one pager, we talked about it will be too much work to
>>>> support every single command line option in the deployment descriptors
>>>> so we will treat them case by case. Is this option worth the work to
>>>> support in the deployment descriptors?
>>> Don't know.
>> Ok, let's have the option supported only through the command line in
>> this release and decide whether to add it in the deployment
>> descriptor in next release based on the user feedback.
>>
>> Thanks,
>>
>> - Hong
>>
>> ---------------------------------------------------------------------
>> 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
>