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
>