There is one more related question: How will this option be specified
for auto-deployment? In each glassfish-xxx.xml separately?
thanks,
-marina
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
>>