Hi,
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).
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?
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?
Thanks,
- Hong
Hong Zhang wrote:
>
>>> There is one more related question: How will this option be
>>> specified for auto-deployment? In each glassfish-xxx.xml separately?
>>>
>>> thanks,
>>> -marina
>>>
>> There is a bigger issue where already many deploy options at the CLI
>> level are not possible via JSR 88 and sun specific deployement
>> descriptors (and JSR 88).
>> I mentioned this to Hong during gf 3.1 deployment onepager review...
> We can add corresponding elements in glassfish-*.xml, and look at the
> element values in the top level glassfish-*.xml (so in ear case, the
> element values in the sub module glassfish-*.xml will be ignored).
>
> Are there any better alternatives?
>
>>
>>> Marina Vatkina wrote:
>>>> We have null value as the default for --dropandcreatetables (which
>>>> has been specified as false in the latest manpages, but the
>>>> documentation explains that if it's not set, the DD settings apply.
>>>>
>>>> But thanks for bringing this up - we'd need to support auto-deploy
>>>> where there are no asadmin options...
>>>>
>>>> thanks,
>>>> -marina
>>>>
>>>> Shing Wai Chan wrote:
>>>>> If we decide to use option and the option can only specify boolean,
>>>>> then how can distinguish the case of "default".
>>>>> In web case, if there is no --property keepSessions=true/false is
>>>>> specified,
>>>>> then we may read the information from other places.
>>>>>
>>>>> On 6/9/10 3:31 PM, Bill Shannon wrote:
>>>>>
>>>>>> Tim Quinn wrote on 06/ 9/10 02:32 PM:
>>>>>>
>>>>>>> The earlier creation of a specific property called keepSessions
>>>>>>> for http
>>>>>>> sessions on web apps implied (to me) that someone thought it
>>>>>>> made sense
>>>>>>> to specifically identify the container type of interest for
>>>>>>> turning this
>>>>>>> on or off. Oherwise why not just have the property keepState or
>>>>>>> introduce a keepState option?
>>>>>>>
>>>>>>> Perhaps I assumed wrong.
>>>>>>
>>>>>>
>>>>>> I think you assume too much.
>>>>>>
>>>>>> Since this feature was only added to support saving session state,
>>>>>> I suspect that's how the name of the property was chosen, without
>>>>>> considering how that might apply in the future as the support was
>>>>>> expanded to cover other state.
>>>>>>
>>>>>>> Anyway, I certainly don't have a specific use case in mind for
>>>>>>> retaining
>>>>>>> some but not all types of state. I do worry some about the point
>>>>>>> Vince
>>>>>>> raised - as soon as we prevent it, someone will want it. His
>>>>>>> suggestion
>>>>>>> for allowing
>>>>>>>
>>>>>>> --keepState (which means "all")
>>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>> --keepState=web,ejb,...
>>>>>>>
>>>>>>> covers all bases. As I and several others have pointed out we'd
>>>>>>> continue
>>>>>>> to support --property=keepSessions=true for backward compatibility.
>>>>>>
>>>>>>
>>>>>> Unfortunately, the asadmin command processing doesn't support
>>>>>> optional
>>>>>> option values, except for boolean options.
>>>>>>
>>>>>>> It's a separate question, as Ludo raises, whether a developer
>>>>>>> using an
>>>>>>> IDE wants to see a toggle for each container type. If the IDE
>>>>>>> use case
>>>>>>> is to retain all or nothing then there is just the single
>>>>>>> toggle: keep
>>>>>>> or not. Right?
>>>>>>
>>>>>>
>>>>>> I strongly believe we should just keep it simple and only offer
>>>>>> the single
>>>>>> boolean - keep or not. And I agree we should promote it to a
>>>>>> command
>>>>>> option, not just a property.
>>>>>>
>>>>>> "Someone might want to" is not really a good use case to justify the
>>>>>> additional complexity of being able to specify which containers,
>>>>>> or which
>>>>>> container types, should keep their state. If, in the future, we
>>>>>> discover
>>>>>> a real use case that justifies the additional complexity, it's
>>>>>> easy enough
>>>>>> to add another option or property.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> 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
>