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