[jboss-as7-dev] subsystem description keys

[Brian Stansberry]

TBH, I don't know what the thinking was that led to the tx subsystem 
using complex attributes instead of resources. I suspect it was just an 
early subsystem and a simple approach was followed.

Using resources is better where possible and IMO should be done here. 
The (fairly minor) impediment is deciding the key (aka child-type) to 
use, e.g. /subsystem=transactions/???=core-environment , 
/subsystem=transactions/???=coordinator etc.

We use key/value pairs as elements in addresses to make it 
straightforward to eventually expose all the resources as MBeans.

The only rules on the keys are

1) Keys must be valid for use in an ObjectName
2) No key can appear in two locations in the same address
3) Use singular form, e.g. connector=http not connectors=http.

On 5/22/11 4:45 PM, Scott Stark wrote:
> It seems a bit arbitrary as to whether a subsystems content is
> addressable or not. What I see for the logging subsystem vs the
> transactions is that I can ls the logging subsystem and individually
> read the children while transactions has no children, hence nothing to
> ls, but there no obvious reason why one or more of the transactions
> attributes could not be addressable resources. What goes into that choice?
>
> [standalone at localhost:9999 /] ls subsystem=logging
> periodic-rotating-file-handler   size-rotating-file-handler
> logger                           file-handler
> async-handler                    console-handler
> [standalone at localhost:9999 /]
> ./subsystem=logging/console-handler=CONSOLE:read-resource
> {
>       "outcome" =>  "success",
>       "result" =>  {
>           "autoflush" =>  true,
>           "encoding" =>  undefined,
>           "formatter" =>  "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n",
>           "level" =>  "INFO",
>           "queue-length" =>  undefined
>       },
>       "compensating-operation" =>  undefined
> }
>
> [standalone at localhost:9999 /] ls subsystem=transactions
> [standalone at localhost:9999 /]
> [standalone at localhost:9999 /] ./subsystem=transactions:read-resource
> {
>       "outcome" =>  "success",
>       "result" =>  {
>           "core-environment" =>  {
>               "process-id" =>  {"uuid" =>  "uuid"},
>               "node-identifier" =>  undefined
>           },
>           "recovery-environment" =>  {
>               "socket-binding" =>  "txn-recovery-environment",
>               "status-socket-binding" =>  "txn-status-manager"
>           },
>           "coordinator-environment" =>  {
>               "enable-statistics" =>  undefined,
>               "default-timeout" =>  undefined
>           },
>           "object-store" =>  {
>               "relative-to" =>  undefined,
>               "path" =>  undefined
>           }
>       },
>       "compensating-operation" =>  undefined
> }
>
> On 5/21/11 2:10 PM, Brian Stansberry wrote:
>> CHILDREN is used for describing the relationship of a parent resource to
>> a child resource. A resource is addressable, has attributes and
>> operations, and may have children.
>>
>> ATTRIBUTE is used for describing attributes. Attributes don't have to be
>> simple types; they can be complex, which is the case with the attributes
>> in the transactions subsystem. But attributes aren't directly
>> addressable; e.g. if you want to read some detail of the
>> CORE_ENVIRONMENT you'd have to read the entire attribute and then access
>> the detail.
>>
>> This is discussed in more detail on
>>
>> http://community.jboss.org/docs/DOC-16317
>>
>> On 5/21/11 12:48 PM, Scott Stark wrote:
>>> I see that some subsystems use CHILDREN as the model key to describe the
>>> subsystem root children, while others are using ATTRIBUTES. It does not
>>> appear to make a different right now, but I assume it will at some point?
>>>
>>> Logging:
>>>                 subsystem.get(CHILDREN, CommonAttributes.ROOT_LOGGER,
>>> DESCRIPTION).set(bundle.getString("root.logger"));
>>>
>>> Transactions:
>>>                 subsystem.get(ATTRIBUTES, CORE_ENVIRONMENT,
>>> DESCRIPTION).set(bundle.getString("core-environment"));
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
> _______________________________________________
> 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