Am 05.01.2011 um 00:46 schrieb David M. Lloyd:
I don't think the keys are needed. just have
http://myserver.foo.com/management/domain/<profile>/<subsystem&g...
The common part like profile name or subsystem (have 'as' for non-subsystem
attributes)
should be enough.
{
"subsystem" => {
"remoting" => {
"endpoint-name" => "${jboss.node.name}",
"server" => {
"ssl" => {
"socket-binding" => "Remoting-SSL",
"authentication-handler" => "MyAuthHandler",
"thread-pool-size" => {
"count" => 1,
"per-cpu" => 1.5f
}
}
}
}
}
}
I can get the remoting subsystem model element via:
[("subsystem" => "remoting")]
Following the above url this would just be
/<profile>/remoting
Assuming we follow the "dangling last item" principle, I
can then get
the endpoint-name attribute then via:
[("subsystem" => "remoting"), "endpoint-name"]
/<profile>/remoting/endpoint-name
Now "server" represents a submodel, so to get at the "ssl" server
model
element it's:
[("subsystem" => "remoting"), ("server" =>
"ssl")]
/<profile>/remoting/server/ssl
or when we already "stand" at /<profile>/remoting just
server/ssl
I really favor xpath like navgation.
If a target node is an attribute (=leaf or set of leafs) , return / modify the attribute.
Otherwise
return the whole subsystem node (or set of nodes).
I am not exactly sure about the need for set-of though.
Probably the best course of action (which you probably have already
taken) is to have subsystems register their model element subschema in
some form so that query and update operations can validate that the
address path at least makes sense.
Is that registration actually compile- or run-time?
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera