Re: [Mc4j-user] MC4J and MBeans Tree
Brought to you by:
ghinkl
Menu
▾
▴
Re: [Mc4j-user] MC4J and MBeans Tree
|
From: Sergey B. <ser...@io...> - 2005-12-13 12:29:29
|
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" <gre...@gm...>
> To: <mc4...@li...>
> 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
>>> Mc4...@li...
>>> 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
>> Mc4...@li...
>> https://lists.sourceforge.net/lists/listinfo/mc4j-user
>
|