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
>