Hi

Or may  be there's a much simplier approach.
If a given ObjectName contains a key-value pair, where the key is equal to a
value of 'type' property of one of the other currently available
ObjectNames, then there's an ancestor-to-descendant relationship here. This
rule applied to all key-value pairs on a givem ObjectName except for "type="
pairs (and perhaps j2eetype=).
If we have
domain:type=A,name=A1
domain:type=B,A=A1,name=B1
domain:type=B,A=A1,name=B2
domain:type=C,A=A1,B=B1,name=C1
domain:type=C,A=A1,B=B2,name=C2

and a rule above, then it's obvious that the tree is :
 A1
 |--B1
 |   |--C1
 |--B2
     |--C2

Cheers, Sergey



> Hi
>
> I think it would be nice, given different views on how beans should be
> ordered,
> to let people provide custom implementations of some interface like
> MBeanTreePresenter
> or smth like that.
> the console could ask it, for ex, given some input ObjectName and a
> collection of currently known MBeans in the same domain this ObjectName
> belongs to, to point to a top level ancestor and an immediate parent for
> this given ObjectName (MBean).
>
> class CustomMBeanTreePresenterFactory implements/extends
> MBeanTreePresenterFactory {
>  MBeanTreePresenter getMBeanTreePresenter(String domain);
> }
>
> interface MBeanTreePresenter{
>    AncestorPair getAncestorPair(ObjectName name, Map/Collection mBeans);
> }
>
> May be something better can be used but it's nic eto be able to provide
> some customization...
>
> What do you think ?
>
> Cheers, Sergey
>
>
> ----- Original Message -----
> From: "Greg Hinkle" <hidden>
> To: <hidden>
> Sent: Thursday, December 08, 2005 3:43 PM
> Subject: Re: [Mc4j-user] MC4J and MBeans Tree
>
>
>> As far as I know, no one has ever followed this containment
>> recommendation and so it is not supported in MC4J. JSR-77 has its own
>> containment policy with externally define hierarchies (though most
>> implementations also puts keys in a contextual order).
>>
>> MC4J currently does largest key group aggregation so that it takes  all
>> beans in a domain and orders their keys by the number of matches.  The
>> beans below would be grouped into a group of all "bar=Y'" beans  because
>> there are more matches than for the foo key. That model  seemed to work
>> fairly well for WebLogic, but its obviously not well  thought out.
>>
>> A:foo=X,bar=Y
>> A:foo=Z,bar=Y
>>
>> I was considering using the key ordering for the next version, but  i'm
>> open to suggestions. Maybe I could provide selectable ordering
>> implementations.
>>
>>
>> On Dec 8, 2005, at 10:16 AM, Sergey Beryozkin wrote:
>>
>>> Hi
>>>
>>> I've just subscribed to this list and here's my first question,
>>> apologies
>>> if a similar question has been asked before.
>>> Here's the problem I need to solve. I'm experimenting with few mgmt
>>> consoles. One of them is MC4J. When it connects to my server it shows
>>> the MBeasn tree in the way I don't expect.
>>>
>>> For example, lets assume I have 'A', 'B', 'C' and 'D' mbeans where  'A'
>>> is a parent to 'B', 'B' to 'C' and
>>> 'C' to 'D'.
>>>
>>> I name them like this :
>>>
>>> SomeDomain:type=A,name=A1
>>> SomeDomain:type=A.B,A=A1,name=B1
>>> SomeDomain:type=A.B.C,A=A1,A.B=B1,name=C1
>>> SomeDomain:type=A.B.C.D,A=A1,A.B=B1,A.B.C=C1,name=D1
>>>
>>>
>>> MC4J will show them to me like this
>>>
>>> SomeDomain
>>> |
>>> -A=A1
>>> |     |
>>> |     --- A.B=B1
>>> |     |
>>> |     ----name=D1,type=A.B.C.D,A.B.C=C1
>>> |     ----name=C1,type=A.B.C
>>> |     |
>>> |     --- name=B1,type=A.B
>>> |
>>> -name=A1,type=A
>>>
>>> I'd appreciate any hints/comments. Apparently, I'm not following  some
>>> well-known ObjectName naming patterns. I tried to follow
>>> recommendations outlined in [1] but it doesnt help.
>>>
>>>
>>> Thanks, Sergey
>>>
>>> [1] http://java.sun.com/products/JavaManagement/best-practices.html
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: Splunk Inc. Do you grep through  log
>>> files
>>> for problems?  Stop!  Download the new AJAX search engine that makes
>>> searching your log files as easy as surfing the  web.  DOWNLOAD  SPLUNK!
>>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>> _______________________________________________
>>> Mc4j-user mailing list
>>> hidden
>>> https://lists.sourceforge.net/lists/listinfo/mc4j-user
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>> files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>> _______________________________________________
>> Mc4j-user mailing list
>> hidden
>> https://lists.sourceforge.net/lists/listinfo/mc4j-user
>



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Mc4j-user mailing list
hidden
https://lists.sourceforge.net/lists/listinfo/mc4j-user