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

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.

My 2c, David

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

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?

Yes, this is the case i mean. If you you do a read-resource(defaults=true) - you get a model with all the default values. If you then just write all attribute we would have to add some sort of check not that we end up storing a default value in the model again.

The first point is no big deal. Verbosity or not. It's always better to strive for a simple, easy to grasp solution. I believe (as a consumer of that API) that it should reflect the effective runtime model, no matter what. Including the defaults. Going through additional hoops & loops to figure out the effective runtime configuration is counter productive (curl,bash, etc) and will not be used.

Further more, consumer do not care if the attribute derives from a default value or not.

IMO point 2 can be neglected. It's an edge case, if you ask me. The first point is no big deal. Verbosity or not. It's always better to strive for a simple, easy to grasp solution. I believe (as a consumer of that API) that it should reflect the effective runtime model, no matter what.

Including the defaults. Going through additional hoops & loops to figure out the effective runtime configuration is counter productive (curl,bash, etc) and will not be used. Further more, consumer do not care if the attribute derives from a default value or not. And why should they?

The fact that it's written back to xml, is an implementation detail to me. But it should not mandate how the actually API works.

I agree, people will want to see whether they specified a particular value or not. But in either case they probably want to see what the effective value is, so if the value isn't specified they will want to see what the default is that is currently being used as long as it's clear that this is the default. In past systems that I worked on this was reflected in the GUI somehow by making the default appear grey and have a 'default' icon beside it... How the GUI obtains that information is an implementation detail.

We also seem to be talking about three different things.

- storing default values in the internal configuration model really does not add any value in the end. Nothing on the server side needs this as part of the model and can be easily added based on the description for the client. This is what Brian was referring to. - exposing defaults in the read-resource operation - i personally would be more interested in what i configured, rather than static defaults. I do see why Ike wants the defaults in the result for the console - i'm just not sure if that should be the default view?