Re: [jboss-as7-dev] Default values in the model
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?