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

[Emanuel Muckenhuber]

Yes, not storing any defaults in the model sounds better and rather have 
the read-resource and read-attribute handler expose this.

What about the write-attribute operation? I would assume that the 
console(s) usually don't differentiate whether a values was really 
changed in the UI and just write all attributes. So we would need to 
check the defaults there as well?

On 07/29/2011 02:31 AM, 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?
>