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.