12:41 a.m.
Can you explore with Alexey Loubyansky and Stefano Maestri (who has a
task to rationalize this subsystem) the possibility of flattening this
out and using the "alternative" metadata descriptors Alexey has proposed.
That is, your proposed format is correct but leads to complex
attributes. If it can instead be a choice between a top level "uuid"
attribute and a pair of "process-id-socket" and
"process-id-socket-max-ports" attributes, with the metadata properly
describing that choice, that would be nice.
The model would have all 3 attributes, but either "uuid" or
"process-id-socket" and "process-id-socket-max-ports" would be
undefined.
On 8/23/11 6:09 AM, Kabir Khan wrote:
When working through problems in the JMX facade I came across this
<xs:complexType name="process-id">
<xs:annotation>
<xs:documentation>
<![CDATA[
The process identifer implementation
The "node-identifier" attribute is used to set the node
identifier on the core environment.
The "socket-process-id-max-ports" attribute is used to set the
max ports on the core environment.
]]>
</xs:documentation>
</xs:annotation>
<xs:choice>
<xs:element name="uuid" type="uuid" />
<xs:element name="socket" type="socket-id" />
</xs:choice>
</xs:complexType>
<xs:complexType name="uuid">
<xs:annotation>
<xs:documentation>
<![CDATA[
The UUID based process identifer implementation
]]>
</xs:documentation>
</xs:annotation>
</xs:complexType>
<xs:complexType name="socket-id">
<xs:annotation>
<xs:documentation>
<![CDATA[
The socket based process identifer implementation
The "socket-binding" attribute is used to specify the port to
bind to.
The "socket-process-id-max-ports" attribute is used to set the
max ports on the core environment.
]]>
</xs:documentation>
</xs:annotation>
<xs:attribute name="socket-binding" type="xs:string"
use="required"/>
<xs:attribute name="socket-process-id-max-ports"
type="xs:int" default="10" />
</xs:complexType>
In the model this is represented as:
"core-environment" => {
"description" => "The core environment
configuration.",
"type" => OBJECT,
"required" => true,
"value-type" => {
"node-identifier" => {
"description" => "Used to set the node
identifier on the core environment.",
"type" => STRING,
"default" => 1,
"required" => false
},
"process-id" => {
"description" => "The Process id type; one of
uuid, socket, file, mbean.",
"type" => OBJECT,
"min-length" => 1,
"required" => true
},
"uuid" => {
"description" => "The process-id/uuid element
indicating to use the UUID based process id.",
"type" => STRING,
"min-length" => 0,
"required" => false
}
},
"access-type" => "read-only",
"storage" => "configuration"
},
The problem is the process-id where type=OBJECT and there is no value_type. From the
schema it looks like it can be either a socket or a uuid. From a quick look at the parser
it looks like both uuid and process-id become children of process-id (so I think the uuid
sibling of process-id is wrong).
However, when possible I think anything with a type=OBJECT should have a value-type,
otherwise the JMX facade has no idea what to do, and needs to fall back to a formatted
JSON string.
I think a better version of this and the corresponding add operation would be:
"value-type" => {
"node-identifier" => {
"description" => "Used to set the node
identifier on the core environment.",
"type" => STRING,
"default" => 1,
"required" => false
},
"process-id" => {
"description" => "The Process id type; one of
uuid, socket, file, mbean.",
"type" => OBJECT,
"min-length" => 1,
"required" => true
"value-type" => {
"uuid" => {
"description" => "The process-id/uuid
element indicating to use the UUID based process id.",
"type" => STRING,
"min-length" => 0,
"required" => false
},
"socket" => {
"type" => "OBJECT",
"value-type" => {
"socket-binding" => STRING,
"socket-process-id-max-ports" => INT
}
}
}
}
}
That way we can specify these properly in the mbean descriptions. Entering JSON stuff by
hand is a pain….
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat