Am 23.03.2011 um 20:41 schrieb Heiko Braun: I think the network interfaces may be a candidate for this as well. Heiko

On 3/23/11 3:15 PM, Jason T. Greene wrote: s/map key/map value -- Jason T. Greene JBoss, a division of Red Hat

But tell me, how should I interpret this one { "jvm" : null } opposed to this one { "jvm" : {"default" : null} } ? On Mar 23, 2011, at 9:23 PM, Heiko Braun wrote:

On 3/23/11 4:18 PM, Jason T. Greene wrote: It might be more correct to have all of the nested values with an assignment of null under this one. -- Jason T. Greene JBoss, a division of Red Hat

On 3/23/11 3:29 PM, Heiko Braun wrote: There is no server-specific JVM configuration; it's inherited from the server-group. The server is configured to use the "default" jvm, no matter what it's server-group might say. It doesn't override any details of the "default" jvm config. This is one area where the key-value pair addressing scheme chafes a bit. Even though there will only be a single jvm=X under a given server-config, the { "jvm" : { "default" : {details}}} layout allows the jvm config to be treated as a resource /server-config=server1/jvm=default and all the details to be attributes of that resource.[1] If "jvm" where an attribute under server-config, then it would just be a big complex blob, with details inaccessible via read-attribute, write-attribute. Everything would require a custom operation. It also allows all the operations on that "kind" of resource to be the same no matter whether it appears as a child of server-config, server-group or host. Under host=X, jvm=A is a natural resource, since there can also be jvm=B. [1] For sure, some of the attributes can be flattened out. For example, there's no reason to have "heap" be a complex attribute with children "size" and "max-size". There can just be "heap-size" and "max-heap-size". -- Brian Stansberry Principal Software Engineer JBoss by Red Hat

On 3/23/11 2:41 PM, Heiko Braun wrote: I touched elsewhere in this thread on the reasons for: "jvm" : {"default" : {...}} But I think the structure underneath that is wrong; looks like a straight mapping of the xml, which isn't necessary. I propose to flatten it out, a la I'll file a JIRA to do that tomorrow unless it's a problem. <snip/> Somewhat, as above. I've also thought about the making the "resource/attribute/children" structure more explicit in what we return from the read-resource operation. We've flattened it out because we store it flat internally and it saves clients calls to modelNode.get(), but it also obscures what a resource is. If changing that would make your life easier, we can do it; it's a fairly simple change. { "attributes" : { "system-properties" : null }, "child-resources" : { "path" : null, "interface" : null, "jvm" : {"default" : { "attributes" : { "heap-size" : "64m", "max-heap-size" : "256m" } } "child-resources" : null } } } There are a limited number of cases where this happens. It's not something that might occur anywhere and has to be generically tested for. We could possibly provide information in the model description about where values are inherited from if they're not defined, but TBH it seems like a wiki page would probably give the same benefit (with a lot less work on our side.) I'm also not opposed to trimming some of the places where things can be configured if it makes things too complex in the UI. Hmm, above I propose doing the opposite! -- Brian Stansberry Principal Software Engineer JBoss by Red Hat