Details
-
Task
-
Resolution: Done
-
Blocker
-
None
-
None
Description
Related to Finding out what version of the Detyped API a client is dealing with
we currently have
[standalone@localhost:9999 /] /subsystem=osgi:read-resource-description { "outcome" => "success", "result" => { "description" => "The the OSGi subsystem configuration.", "head-comment-allowed" => true, "tail-comment-allowed" => true, "namespace" => "urn:jboss:domain:osgi:1.0", "attributes" => { "activation" => { "description" => "Activation flag for the OSGi subsystem. Possible values: lazy, eager.", "type" => STRING, "default" => "LAZY", "access-type" => "read-write", "restart-required" => "no-services", "storage" => "configuration" }, "startlevel" => { "description" => "The current Start Level of the OSGi Framework. Changing this value will change the start level of the Framework accordingly. ", "type" => INT, "access-type" => "read-write", "restart-required" => "no-services", "storage" => "runtime" } }, "children" => { "configuration" => {"description" => "A configuration entry."}, "property" => {"description" => "A framework property."}, "capability" => {"description" => "A framework capability."}, "bundle" => {"description" => "Runtime bundle information."} } } }
The namespace definition of the model
"namespace" => "urn:jboss:domain:osgi:1.0",
is that of the XML representation - worse, it is that of an outdated XML representation.
Some subsystems do not define a namespace for their model at all.
I suggest to define an individual namespace per subsystem with some compatibility rule encoded within.
Management clients can then decide whether and to what extend they can manage that subsystem.