[jboss-as7-dev] 'choices' in model (Transaction subsystem)

[Brian Stansberry]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat