[jboss-as7-dev] Default values in the model

[Brian Stansberry]

On 7/29/11 3:43 PM, David Bosschaert wrote:
> On 29/07/2011 01:31, Brian Stansberry wrote:
>> Emanuel,
>>
>> Or chat yesterday about the downsides of storing default values in the
>> in-memory management model got me thinking a bit.
>>
>> Downsides:
>>
>> 1) The in-memory model no longer represents the user configuration
>> values; it also stores defaults. This is an issue when marshalling back
>> to xml; you either have to make the xml verbose by writing back all the
>> defaults, or you don't write back defaults and lose the fact the user
>> included the value in the original.
>>
>> 2) Possible versioning issues in a domain where different hosts run
>> different versions; i.e. if the version on the domain controller host
>> stores and pushes to servers a default value that a server running an
>> earlier version doesn't understand. This would really be a bug, since a
>> change in a default value should spur an increment in the subsystem's
>> schema and appropriate handling by the parser. But still, storing
>> defaults increases the chances of this kind of bug cropping up.
>>
>> Possible solution:
>>
>> What's been requested previously is that management clients be able to
>> see the default values, without having to go read the resource
>> description metadata to find them. That request can be satisfied via the
>> read-resource and read-attribute handlers. There is no need to store the
>> default in the model; those handlers can read the resource description
>> metadata to find the default if the model doesn't have a value stored.
>>
>> That will slow those handlers down a little bit since the description
>> has to be generated and read, but those handlers aren't called as part
>> of our internal operations (e.g. boot) so doing it that way won't slow
>> down boot, deployment etc.
>>
>> An issue that doing it this way raises is a client calling read-resource
>> or read-attribute doesn't know if the returned value is the actual user
>> config or is a default. A solution to that is to have those operations
>> accept a new parameter "defaults" which if false does not include the
>> defaults.
>>
>> I'm not sure what the best default value for that "default" param would
>> be. My instinct is "true".
>>
>> WDYT?
>>
>
> I personally wouldn't do this. I would leave the default out of the
> read-resource etc result.  That would keep things clear. When you obtain
> the model you'll see that the value isn't specified. A management client
> can easily also obtain the default from the description and nicely
> present this to the user. The management client may actually want to
> mark the default value as such for the users in a slightly different way
> so having it come in somewhat separate can actually be helpful I think.
>

Thanks for the input. This was the original design, but there was a 
discussion of that a few months back, I believe on this list, and what 
came out of it was a desire, I believe by the console guys, to have the 
data available from :read-resource with no extra operation required. 
This is inconsistently implemented now and I'm adding some support code 
to make dealing with defaults and other aspects of attribute handling 
easier, so it has come up again.

Either way, if defaults exist, their value (and units) should be in the 
description metadata; see 
http://community.jboss.org/wiki/DetypedDescriptionOfTheAS7ManagementModel "Arbitrary 
Descriptors".

> My 2c,
>
> David
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat