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.
