[jboss-as7-dev] RFC: Model normalization

Brian Stansberry brian.stansberry at redhat.com
Wed Mar 23 18:14:58 EDT 2011


On 3/23/11 2:41 PM, Heiko Braun wrote:
>
>
> [INFO] {
> [INFO]     "path" : null,
> [INFO]     "system-property" : null,
> [INFO]     "interface" : null,
> [INFO]     "jvm" : {"default" : {"heap" : {
> [INFO]         "size" : "64m",
> [INFO]         "max-size" : "256m"
> [INFO]     }}},

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

 > [INFO]     "jvm" : {"default" : {
 > [INFO]         "heap-size" : "64m",
 > [INFO]         "max-heap-size" : "256m"
 > [INFO]     }},

I'll file a JIRA to do that tomorrow unless it's a problem.

<snip/>


>
> IMO we need to think thoroughly about the following questions:
>
> - Can the model be normalized somehow?

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
      }
   }
}

> - How do we deal with inherited properties?

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.

> - Would it make sense to separate the actual state from the structural information?
>

Hmm, above I propose doing the opposite!

> Ike
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat



More information about the jboss-as7-dev mailing list