>> 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
>