A brief summary:
- com.sun.appserv was a private API in V2. AMX was/is the public API
for V2/V3. In theory, no one should have cared about "category"
- v2 AMX was 100% consistent in its ObjectNames as will be V3
- v2 com.sun.appserv MBeans had a number of inconsistencies (some
MBeans missing the category property and some "kitchen sink" MBeans
lumped in with other config MBeans, no clear distinction between
runtime and config, etc).
- AMX already has a "Group" attribute (not in the ObjectName).
...
Adding a "category" property to AMX is a significant change, and the
benefits are very limited.: the ability to qy
One can query on "category" to find all MBeans of that category. But
unless a precisely defined policy is promulgated, this rapidly becomes
an ambiguous feature. Defining categories is harder than it seems and
once this is done, there are all sorts of other useful properties that
could be added. But who would need this feature? Certainly it can be
useful for debugging (eg in JConsole or jmxcmd). But jmxcmd at least
already has powerful facilities that make this unnecessary (eg
wildcard search).
Once properties are added to an ObjectName, the temptation is to add
more...there is always some seemingly useful property that can be added.
But the bottom line is that for our GUI and CLI, I don't see any
useful need for this. If there is, AMX could simply provide a
getByGroup() method which accomplishes the same thing (and any other
number of methods to slice and dice, see the QueryMgr).
Lloyd
On Mar 19, 2008, at 12:30 PM, Sreenivas Munnangi wrote:
> Jerome Dochez wrote:
>> so do we already have an inconsistency in v2 ?
> Let me clarify.
>
> In V2, for all the MBeans (other than AMX) there is category key in
> the object name, for ex. category=config for config mBeans,
> category=runtime for jsr77 mBeans and category=monitor for
> monitoring mBeans.
>
> Now we are planning to have just one set of mBeans, which is AMX and
> the question is should we have a key similar to category and what
> are the pros and cons.
>>
>>
>> Sreenivas Munnangi wrote:
>>> Lloyd L Chambers wrote:
>>>> Sreeni,
>>>>
>>>> Please don't do this unless ALL of AMX does--it's a consistency
>>>> issue; AMX is *one* API not a mishmash of unrelated MBeans.
>>>>
>>>> The benefits must be clearly understood before making such an
>>>> (incompatible) decision.
>>> I was explaining the V2 behavior and I agree we need to be
>>> consistent.
>>>>
>>>> Lloyd
>>>>
>>>> On Mar 18, 2008, at 1:34 PM, Sreenivas Munnangi wrote:
>>>>> Lloyd,
>>>>>
>>>>> I am sure you know this but for the benefit of others, in V2 all
>>>>> the jsr77 runtime mebans have "category=runtime" as part of its
>>>>> object name. Then it is possible to query only the runtime mbeans.
>>>>>
>>>>> thanks
>>>>> sreeni
>>>>>
>>>>> Lloyd L Chambers wrote:
>>>>>> One issue I'm considering for AMX ObjectNames is whether to
>>>>>> include a property in the ObjectName which categorizes the
>>>>>> MBean eg "config", "runtime", etc.
>>>>>>
>>>>>> In V2 AMX had no such thing; ObjectNames were strictly limited
>>>>>> only to properties that made the ObjectName unique among
>>>>>> others. However, the "com.sun.appserv:" MBeans did have a
>>>>>> "category" property.
>>>>>>
>>>>>> Why add such a property? (And where does one stop?!). It can
>>>>>> be useful for selecting a subset of MBeans based on
>>>>>> functionality eg "all config MBeans".
>>>>>>
>>>>>> WITHOUT: amx:j2eeType=X-DomainConfig,name=amx (Glassfish V2)
>>>>>> POSSIBLE: amx:j2eeType=X-
>>>>>> DomainConfig,name=na,grp=config // possible change, 'grp' =
>>>>>> "group"
>>>>>>
>>>>>> AMX MBeans already have a "Group" Attribute which does this,
>>>>>> but one cannot query ObjectNames based on MBean attributes.
>>>>>> Note also that the value of the j2eeType field is 100%
>>>>>> consistent eg everything ending in "Config" is a config MBean--
>>>>>> but again, not actionable via queryNames().
>>>>>>
>>>>>> I'm inclined to stick with the V2 style even though a group or
>>>>>> category property is handy ('grp'). Comments welcome.
>>>>>>
>>>>>> Lloyd
>>>>>>
>>>>>> ---
>>>>>> Lloyd L Chambers
>>>>>> lloyd.chambers_at_sun.com
>>>>>> Sun Microsystems, Inc
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: admin-
>>>>>> help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>> ---
>>>> Lloyd L Chambers
>>>> lloyd.chambers_at_sun.com
>>>> Sun Microsystems, Inc
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc