I think the argument cuts both ways. At least we've had the
conversation now, and I hope I'm wrong. :)
On Sep 23, 2008, at 3:32 PM, Jerome Dochez wrote:
> Lloyd Chambers wrote:
>> In an upgrade scenario, I would expect my settings to remain the
>> same, not to take on new values.
> what about if you server does not start... or does not function
> optimally.
>
> Did you make explicit administrative operations in your previous
> installations that you wanted those values ? This can be argumented
> both ways like most things, however it seems to me that when a user
> is trusting the application server default values, it expects the
> same when upgrading and not necessarily running with the old
> installation default values which could provide a degraded runtime
> environment in the new installation.
>
>
>>
>> On Sep 23, 2008, at 3:01 PM, Kedar Mhaswade wrote:
>>
>>>
>>>>> I also think it's very confusing to users to not write out that
>>>>> default value.
>>>> the main problem with writing out the default value in the
>>>> domain.xml is that if we decide that the default value should be
>>>> changed between releases *and* we are dealing with an upgrade
>>>> scenario then the user would retain the previous default value
>>>> which was clearly not his intent.
>>>
>>> That's right, but don't you think that a change in default value
>>> is a source
>>> of incompatibility?
>>>
>>> (It really boils down to whether our @Configured interfaces are
>>> our product
>>> interfaces because default values are now in annotations on them).
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>