Thread: [Springframework-developer] Spring JMX Query

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

All,

I have raised a new issue on JIRA related to Spring JMX and I would like 
your input: http://opensource.atlassian.com/projects/spring/browse/SPR-498.

Rob

Rob,

Commons-modeler has such a format for defining model mbean metadata in XML,
and an associated Registry allowing MBeanInfo definitions to be indexed by
'type' (essentially a logical management class identifier) and shared
between different MBean instances (perhaps backed by different POJO
implementations.)

In my experience where the format breaks down is with MBean inheritance.  It
would extremely helpful if you could define base management interfaces with
metadata and be able to extend to derive more specific management types.
For anyone whose ever done any network management work, this is important.
Look at JSR-77, it's basically defines a management hierarchy as well.

Do we have the ability to define management interfaces in java code (with an
inheritance hierarchy), markup those interfaces with management metadata,
and generate corresponding MBeanInfos at runtime that can be shared?  I
wonder if that would work.  I'd much rather apply attributes to the
management interfaces than the managed beans themselves...

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Rob Harrop
Sent: Monday, November 29, 2004 11:18 AM
To: spr...@li...
Subject: [Springframework-developer] Spring JMX Query

All,

I have raised a new issue on JIRA related to Spring JMX and I would like 
your input: http://opensource.atlassian.com/projects/spring/browse/SPR-498.

Rob

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Keith,

I have a passing familiarity with Commons Modeler and I understand what 
you mean about the inheritance. However, it should be more than possible 
to allow for mgmt interface inheritance using XML - there is no reason 
it couldn't be done. As for defining the mgmt interface in code - aren't 
we getting into the realms of recreating what JMX does already? Add to 
that I'm not sure how all the different metadata utils such as Commons 
Attributes handle inheritance - I'll need to check that out.

Rob

Keith Donald wrote:

>Rob,
>
>Commons-modeler has such a format for defining model mbean metadata in XML,
>and an associated Registry allowing MBeanInfo definitions to be indexed by
>'type' (essentially a logical management class identifier) and shared
>between different MBean instances (perhaps backed by different POJO
>implementations.)
>
>In my experience where the format breaks down is with MBean inheritance.  It
>would extremely helpful if you could define base management interfaces with
>metadata and be able to extend to derive more specific management types.
>For anyone whose ever done any network management work, this is important.
>Look at JSR-77, it's basically defines a management hierarchy as well.
>
>Do we have the ability to define management interfaces in java code (with an
>inheritance hierarchy), markup those interfaces with management metadata,
>and generate corresponding MBeanInfos at runtime that can be shared?  I
>wonder if that would work.  I'd much rather apply attributes to the
>management interfaces than the managed beans themselves...
>
>Keith
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Rob Harrop
>Sent: Monday, November 29, 2004 11:18 AM
>To: spr...@li...
>Subject: [Springframework-developer] Spring JMX Query
>
>All,
>
>I have raised a new issue on JIRA related to Spring JMX and I would like 
>your input: http://opensource.atlassian.com/projects/spring/browse/SPR-498.
>
>Rob
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

>As for defining the mgmt interface in code - aren't 
>we getting into the realms of recreating what JMX does already?

No, JMX employs different strategies for getting to the same thing; that is,
a configured management descriptor (MBeanInfo) describing a manageable
object.

As you know, one of these strategies is reflection: you have your bean
implement a "*MBean" interface and JMX uses reflection to generate a new
MBeanInfo descriptor when your bean is registered with the MBeanServer.  But
this has limitations: there is only so much you can find out from
reflection.  And MBeanInfos are not shared.

Another strategy involves creating populated MBeanInfo instances ahead of
time, to support dynamic mbeans and model mbeans.  You specify the
descriptor separately and at runtime a DynamicMBean or RequiredModelMBean
proxy connects the descriptor with the managed bean instance.  In these
cases you're not required to define a strongly typed management interface at
all.

I prefer strongly typed POJO management interfaces combined with
descriptive, configurable management metadata that can be shared between
POJO implementations that are of the same _logical type_.  For example,
let's say we have a logical type, like the JSR-77 "Service".  Such a type
can be expressed via a POJO management interface -- Service --, with methods
like start(), and stop().  Such an interface might also extend a base
management interface used by all managed entities, like
"ManagedSystemElement".

In this example, I'd prefer my POJOs to implement Service, and I'd prefer to
have a shared "Service MBeanInfo" instance providing metadata about the
attributes, operations, and notifications instrumented by all services.  At
runtime, I'd expect my MBean adapter to note my bean is a "Service" and
locate the right MBeanInfo descriptor for registration in an MBeanServer as
a ModelMBean.

One way of providing MBeanInfo information is XML, but I'd just assume have
it defined in java-code using annotations---cutting out the need for
reflection.

My only caveat with such a solution is many times you want a much more
generically typed management model exposed to _clients_: e.g with strings,
primitives, object names, and generic tabular/composite data structure types
ONLY, while the _interal_ workings of your managed beans want a richly typed
model to work with.  This is because you can't often make the assumption all
your management clients have access to your classes, or that they're even
all java.  So I can see a need for our JMX support to create translators
that map between a richly typed model to a more generic management model.

Keith

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Rob Harrop
Sent: Monday, November 29, 2004 11:44 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring JMX Query

Keith,

I have a passing familiarity with Commons Modeler and I understand what 
you mean about the inheritance. However, it should be more than possible 
to allow for mgmt interface inheritance using XML - there is no reason 
it couldn't be done. As for defining the mgmt interface in code - aren't 
we getting into the realms of recreating what JMX does already? Add to 
that I'm not sure how all the different metadata utils such as Commons 
Attributes handle inheritance - I'll need to check that out.

Rob

Keith Donald wrote:

>Rob,
>
>Commons-modeler has such a format for defining model mbean metadata in XML,
>and an associated Registry allowing MBeanInfo definitions to be indexed by
>'type' (essentially a logical management class identifier) and shared
>between different MBean instances (perhaps backed by different POJO
>implementations.)
>
>In my experience where the format breaks down is with MBean inheritance.
It
>would extremely helpful if you could define base management interfaces with
>metadata and be able to extend to derive more specific management types.
>For anyone whose ever done any network management work, this is important.
>Look at JSR-77, it's basically defines a management hierarchy as well.
>
>Do we have the ability to define management interfaces in java code (with
an
>inheritance hierarchy), markup those interfaces with management metadata,
>and generate corresponding MBeanInfos at runtime that can be shared?  I
>wonder if that would work.  I'd much rather apply attributes to the
>management interfaces than the managed beans themselves...
>
>Keith
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Rob Harrop
>Sent: Monday, November 29, 2004 11:18 AM
>To: spr...@li...
>Subject: [Springframework-developer] Spring JMX Query
>
>All,
>
>I have raised a new issue on JIRA related to Spring JMX and I would like 
>your input: http://opensource.atlassian.com/projects/spring/browse/SPR-498.
>
>Rob
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Keith,

I understand what you are aiming at with this approach and I think it 
may be worthwhile me putting together an assembler based on this 
approach, the only problem it doesn't solve is allowing for mgmt 
interface to be modified without modifying the code. I have a question 
though. You mentioned sharing the MBeanInfo objects to serve multiple 
different managed resources. I don't know if this would work since the 
MBeanInfo is used to store a lot of instance specific data such as 
default values and cached data. If you were to share MBeanInfo instance 
you would end up with the cached values colliding.

Rob

Keith Donald wrote:

>>As for defining the mgmt interface in code - aren't 
>>we getting into the realms of recreating what JMX does already?
>>    
>>
>
>No, JMX employs different strategies for getting to the same thing; that is,
>a configured management descriptor (MBeanInfo) describing a manageable
>object.
>
>As you know, one of these strategies is reflection: you have your bean
>implement a "*MBean" interface and JMX uses reflection to generate a new
>MBeanInfo descriptor when your bean is registered with the MBeanServer.  But
>this has limitations: there is only so much you can find out from
>reflection.  And MBeanInfos are not shared.
>
>Another strategy involves creating populated MBeanInfo instances ahead of
>time, to support dynamic mbeans and model mbeans.  You specify the
>descriptor separately and at runtime a DynamicMBean or RequiredModelMBean
>proxy connects the descriptor with the managed bean instance.  In these
>cases you're not required to define a strongly typed management interface at
>all.
>
>I prefer strongly typed POJO management interfaces combined with
>descriptive, configurable management metadata that can be shared between
>POJO implementations that are of the same _logical type_.  For example,
>let's say we have a logical type, like the JSR-77 "Service".  Such a type
>can be expressed via a POJO management interface -- Service --, with methods
>like start(), and stop().  Such an interface might also extend a base
>management interface used by all managed entities, like
>"ManagedSystemElement".
>
>In this example, I'd prefer my POJOs to implement Service, and I'd prefer to
>have a shared "Service MBeanInfo" instance providing metadata about the
>attributes, operations, and notifications instrumented by all services.  At
>runtime, I'd expect my MBean adapter to note my bean is a "Service" and
>locate the right MBeanInfo descriptor for registration in an MBeanServer as
>a ModelMBean.
>
>One way of providing MBeanInfo information is XML, but I'd just assume have
>it defined in java-code using annotations---cutting out the need for
>reflection.
>
>My only caveat with such a solution is many times you want a much more
>generically typed management model exposed to _clients_: e.g with strings,
>primitives, object names, and generic tabular/composite data structure types
>ONLY, while the _interal_ workings of your managed beans want a richly typed
>model to work with.  This is because you can't often make the assumption all
>your management clients have access to your classes, or that they're even
>all java.  So I can see a need for our JMX support to create translators
>that map between a richly typed model to a more generic management model.
>
>Keith
>
>
>Keith
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Rob Harrop
>Sent: Monday, November 29, 2004 11:44 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Spring JMX Query
>
>Keith,
>
>I have a passing familiarity with Commons Modeler and I understand what 
>you mean about the inheritance. However, it should be more than possible 
>to allow for mgmt interface inheritance using XML - there is no reason 
>it couldn't be done. As for defining the mgmt interface in code - aren't 
>we getting into the realms of recreating what JMX does already? Add to 
>that I'm not sure how all the different metadata utils such as Commons 
>Attributes handle inheritance - I'll need to check that out.
>
>Rob
>
>Keith Donald wrote:
>
>  
>
>>Rob,
>>
>>Commons-modeler has such a format for defining model mbean metadata in XML,
>>and an associated Registry allowing MBeanInfo definitions to be indexed by
>>'type' (essentially a logical management class identifier) and shared
>>between different MBean instances (perhaps backed by different POJO
>>implementations.)
>>
>>In my experience where the format breaks down is with MBean inheritance.
>>    
>>
>It
>  
>
>>would extremely helpful if you could define base management interfaces with
>>metadata and be able to extend to derive more specific management types.
>>For anyone whose ever done any network management work, this is important.
>>Look at JSR-77, it's basically defines a management hierarchy as well.
>>
>>Do we have the ability to define management interfaces in java code (with
>>    
>>
>an
>  
>
>>inheritance hierarchy), markup those interfaces with management metadata,
>>and generate corresponding MBeanInfos at runtime that can be shared?  I
>>wonder if that would work.  I'd much rather apply attributes to the
>>management interfaces than the managed beans themselves...
>>
>>Keith
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On Behalf Of
>>Rob Harrop
>>Sent: Monday, November 29, 2004 11:18 AM
>>To: spr...@li...
>>Subject: [Springframework-developer] Spring JMX Query
>>
>>All,
>>
>>I have raised a new issue on JIRA related to Spring JMX and I would like 
>>your input: http://opensource.atlassian.com/projects/spring/browse/SPR-498.
>>
>>Rob
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now. 
>>http://productguide.itmanagersjournal.com/
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now. 
>>http://productguide.itmanagersjournal.com/
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>> 
>>
>>    
>>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

Thinking on from this - you should be able to do this straight away when 
the JSR-175 support is added since you get metadata inheritance included 
with that, so you can just define you mgmt interfaces with the 
appropriate metadata, implement these interfaces in your beans and 
Spring will then pick up the attributes automatically.

Rob

Rob Harrop wrote:

> Keith,
>
> I understand what you are aiming at with this approach and I think it 
> may be worthwhile me putting together an assembler based on this 
> approach, the only problem it doesn't solve is allowing for mgmt 
> interface to be modified without modifying the code. I have a question 
> though. You mentioned sharing the MBeanInfo objects to serve multiple 
> different managed resources. I don't know if this would work since the 
> MBeanInfo is used to store a lot of instance specific data such as 
> default values and cached data. If you were to share MBeanInfo 
> instance you would end up with the cached values colliding.
>
> Rob
>
> Keith Donald wrote:
>
>>> As for defining the mgmt interface in code - aren't we getting into 
>>> the realms of recreating what JMX does already?
>>>   
>>
>>
>> No, JMX employs different strategies for getting to the same thing; 
>> that is,
>> a configured management descriptor (MBeanInfo) describing a manageable
>> object.
>>
>> As you know, one of these strategies is reflection: you have your bean
>> implement a "*MBean" interface and JMX uses reflection to generate a new
>> MBeanInfo descriptor when your bean is registered with the 
>> MBeanServer.  But
>> this has limitations: there is only so much you can find out from
>> reflection.  And MBeanInfos are not shared.
>>
>> Another strategy involves creating populated MBeanInfo instances 
>> ahead of
>> time, to support dynamic mbeans and model mbeans.  You specify the
>> descriptor separately and at runtime a DynamicMBean or 
>> RequiredModelMBean
>> proxy connects the descriptor with the managed bean instance.  In these
>> cases you're not required to define a strongly typed management 
>> interface at
>> all.
>>
>> I prefer strongly typed POJO management interfaces combined with
>> descriptive, configurable management metadata that can be shared between
>> POJO implementations that are of the same _logical type_.  For example,
>> let's say we have a logical type, like the JSR-77 "Service".  Such a 
>> type
>> can be expressed via a POJO management interface -- Service --, with 
>> methods
>> like start(), and stop().  Such an interface might also extend a base
>> management interface used by all managed entities, like
>> "ManagedSystemElement".
>>
>> In this example, I'd prefer my POJOs to implement Service, and I'd 
>> prefer to
>> have a shared "Service MBeanInfo" instance providing metadata about the
>> attributes, operations, and notifications instrumented by all 
>> services.  At
>> runtime, I'd expect my MBean adapter to note my bean is a "Service" and
>> locate the right MBeanInfo descriptor for registration in an 
>> MBeanServer as
>> a ModelMBean.
>>
>> One way of providing MBeanInfo information is XML, but I'd just 
>> assume have
>> it defined in java-code using annotations---cutting out the need for
>> reflection.
>>
>> My only caveat with such a solution is many times you want a much more
>> generically typed management model exposed to _clients_: e.g with 
>> strings,
>> primitives, object names, and generic tabular/composite data 
>> structure types
>> ONLY, while the _interal_ workings of your managed beans want a 
>> richly typed
>> model to work with.  This is because you can't often make the 
>> assumption all
>> your management clients have access to your classes, or that they're 
>> even
>> all java.  So I can see a need for our JMX support to create translators
>> that map between a richly typed model to a more generic management 
>> model.
>>
>> Keith
>>
>>
>> Keith
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On 
>> Behalf Of
>> Rob Harrop
>> Sent: Monday, November 29, 2004 11:44 AM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] Spring JMX Query
>>
>> Keith,
>>
>> I have a passing familiarity with Commons Modeler and I understand 
>> what you mean about the inheritance. However, it should be more than 
>> possible to allow for mgmt interface inheritance using XML - there is 
>> no reason it couldn't be done. As for defining the mgmt interface in 
>> code - aren't we getting into the realms of recreating what JMX does 
>> already? Add to that I'm not sure how all the different metadata 
>> utils such as Commons Attributes handle inheritance - I'll need to 
>> check that out.
>>
>> Rob
>>
>> Keith Donald wrote:
>>
>>  
>>
>>> Rob,
>>>
>>> Commons-modeler has such a format for defining model mbean metadata 
>>> in XML,
>>> and an associated Registry allowing MBeanInfo definitions to be 
>>> indexed by
>>> 'type' (essentially a logical management class identifier) and shared
>>> between different MBean instances (perhaps backed by different POJO
>>> implementations.)
>>>
>>> In my experience where the format breaks down is with MBean 
>>> inheritance.
>>>   
>>
>> It
>>  
>>
>>> would extremely helpful if you could define base management 
>>> interfaces with
>>> metadata and be able to extend to derive more specific management 
>>> types.
>>> For anyone whose ever done any network management work, this is 
>>> important.
>>> Look at JSR-77, it's basically defines a management hierarchy as well.
>>>
>>> Do we have the ability to define management interfaces in java code 
>>> (with
>>>   
>>
>> an
>>  
>>
>>> inheritance hierarchy), markup those interfaces with management 
>>> metadata,
>>> and generate corresponding MBeanInfos at runtime that can be shared?  I
>>> wonder if that would work.  I'd much rather apply attributes to the
>>> management interfaces than the managed beans themselves...
>>>
>>> Keith
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> [mailto:spr...@li...] On 
>>> Behalf Of
>>> Rob Harrop
>>> Sent: Monday, November 29, 2004 11:18 AM
>>> To: spr...@li...
>>> Subject: [Springframework-developer] Spring JMX Query
>>>
>>> All,
>>>
>>> I have raised a new issue on JIRA related to Spring JMX and I would 
>>> like your input: 
>>> http://opensource.atlassian.com/projects/spring/browse/SPR-498.
>>>
>>> Rob
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real 
>>> users.
>>> Discover which products truly live up to the hype. Start reading 
>>> now. http://productguide.itmanagersjournal.com/
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real 
>>> users.
>>> Discover which products truly live up to the hype. Start reading 
>>> now. http://productguide.itmanagersjournal.com/
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>
>>>
>>>   
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now. 
>> http://productguide.itmanagersjournal.com/
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now. 
>> http://productguide.itmanagersjournal.com/
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>  
>>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

Good point.  Yea, if you're using the MBeanInfo to store instance-specific
data (only possible with the model mbean descriptors, right?), like cached
values (to avoid putting load on the target managed object) you can't share
them...

>approach, the only problem it doesn't solve is allowing for mgmt 
>interface to be modified without modifying the code.

How often do you modify management metadata?  In my experience, the
management model, once defined, stays pretty fixed.  That's critically
important, actually, when you're talking about a enterprise wide management
system.  That's the whole reason the standard management models like DMTF's
CIM exist.

On the other hand, I could very well see some of the _values_ for some of
the metadata coming from externally source locations: like locale
translatable descriptions/attributes.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Rob Harrop
Sent: Monday, November 29, 2004 12:31 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring JMX Query

Keith,

I understand what you are aiming at with this approach and I think it 
may be worthwhile me putting together an assembler based on this 
approach, the only problem it doesn't solve is allowing for mgmt 
interface to be modified without modifying the code. I have a question 
though. You mentioned sharing the MBeanInfo objects to serve multiple 
different managed resources. I don't know if this would work since the 
MBeanInfo is used to store a lot of instance specific data such as 
default values and cached data. If you were to share MBeanInfo instance 
you would end up with the cached values colliding.

Rob

Keith Donald wrote:

>>As for defining the mgmt interface in code - aren't 
>>we getting into the realms of recreating what JMX does already?
>>    
>>
>
>No, JMX employs different strategies for getting to the same thing; that
is,
>a configured management descriptor (MBeanInfo) describing a manageable
>object.
>
>As you know, one of these strategies is reflection: you have your bean
>implement a "*MBean" interface and JMX uses reflection to generate a new
>MBeanInfo descriptor when your bean is registered with the MBeanServer.
But
>this has limitations: there is only so much you can find out from
>reflection.  And MBeanInfos are not shared.
>
>Another strategy involves creating populated MBeanInfo instances ahead of
>time, to support dynamic mbeans and model mbeans.  You specify the
>descriptor separately and at runtime a DynamicMBean or RequiredModelMBean
>proxy connects the descriptor with the managed bean instance.  In these
>cases you're not required to define a strongly typed management interface
at
>all.
>
>I prefer strongly typed POJO management interfaces combined with
>descriptive, configurable management metadata that can be shared between
>POJO implementations that are of the same _logical type_.  For example,
>let's say we have a logical type, like the JSR-77 "Service".  Such a type
>can be expressed via a POJO management interface -- Service --, with
methods
>like start(), and stop().  Such an interface might also extend a base
>management interface used by all managed entities, like
>"ManagedSystemElement".
>
>In this example, I'd prefer my POJOs to implement Service, and I'd prefer
to
>have a shared "Service MBeanInfo" instance providing metadata about the
>attributes, operations, and notifications instrumented by all services.  At
>runtime, I'd expect my MBean adapter to note my bean is a "Service" and
>locate the right MBeanInfo descriptor for registration in an MBeanServer as
>a ModelMBean.
>
>One way of providing MBeanInfo information is XML, but I'd just assume have
>it defined in java-code using annotations---cutting out the need for
>reflection.
>
>My only caveat with such a solution is many times you want a much more
>generically typed management model exposed to _clients_: e.g with strings,
>primitives, object names, and generic tabular/composite data structure
types
>ONLY, while the _interal_ workings of your managed beans want a richly
typed
>model to work with.  This is because you can't often make the assumption
all
>your management clients have access to your classes, or that they're even
>all java.  So I can see a need for our JMX support to create translators
>that map between a richly typed model to a more generic management model.
>
>Keith
>
>
>Keith
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Rob Harrop
>Sent: Monday, November 29, 2004 11:44 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Spring JMX Query
>
>Keith,
>
>I have a passing familiarity with Commons Modeler and I understand what 
>you mean about the inheritance. However, it should be more than possible 
>to allow for mgmt interface inheritance using XML - there is no reason 
>it couldn't be done. As for defining the mgmt interface in code - aren't 
>we getting into the realms of recreating what JMX does already? Add to 
>that I'm not sure how all the different metadata utils such as Commons 
>Attributes handle inheritance - I'll need to check that out.
>
>Rob
>
>Keith Donald wrote:
>
>  
>
>>Rob,
>>
>>Commons-modeler has such a format for defining model mbean metadata in
XML,
>>and an associated Registry allowing MBeanInfo definitions to be indexed by
>>'type' (essentially a logical management class identifier) and shared
>>between different MBean instances (perhaps backed by different POJO
>>implementations.)
>>
>>In my experience where the format breaks down is with MBean inheritance.
>>    
>>
>It
>  
>
>>would extremely helpful if you could define base management interfaces
with
>>metadata and be able to extend to derive more specific management types.
>>For anyone whose ever done any network management work, this is important.
>>Look at JSR-77, it's basically defines a management hierarchy as well.
>>
>>Do we have the ability to define management interfaces in java code (with
>>    
>>
>an
>  
>
>>inheritance hierarchy), markup those interfaces with management metadata,
>>and generate corresponding MBeanInfos at runtime that can be shared?  I
>>wonder if that would work.  I'd much rather apply attributes to the
>>management interfaces than the managed beans themselves...
>>
>>Keith
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On Behalf
Of
>>Rob Harrop
>>Sent: Monday, November 29, 2004 11:18 AM
>>To: spr...@li...
>>Subject: [Springframework-developer] Spring JMX Query
>>
>>All,
>>
>>I have raised a new issue on JIRA related to Spring JMX and I would like 
>>your input:
http://opensource.atlassian.com/projects/spring/browse/SPR-498.
>>
>>Rob
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now. 
>>http://productguide.itmanagersjournal.com/
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now. 
>>http://productguide.itmanagersjournal.com/
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>> 
>>
>>    
>>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Keith,

Yes, you can only enable that behaviour using the descriptors, but it is 
cool behaviour and I started work today adding support for the standard 
descriptors to the metadata assembler in Spring so you can configure 
caching, persistence and such. However, I still think this is a good 
approach even when using individual instances of MBeanInfo. I am going 
to start on JSR-175 support tomorrow and I think I can get this working 
simply by making the annotations inheritable - the 
MetadataModelMBeanInfoAssembler shouldn't need much in the way of a 
modification.

How do you feel about the XML descriptor system as well as this one, 
allowing for a mgmt interface to be changed easily and without having to 
modify the code.

Rob

Keith Donald wrote:

>Good point.  Yea, if you're using the MBeanInfo to store instance-specific
>data (only possible with the model mbean descriptors, right?), like cached
>values (to avoid putting load on the target managed object) you can't share
>them...
>
>  
>
>>approach, the only problem it doesn't solve is allowing for mgmt 
>>interface to be modified without modifying the code.
>>    
>>
>
>How often do you modify management metadata?  In my experience, the
>management model, once defined, stays pretty fixed.  That's critically
>important, actually, when you're talking about a enterprise wide management
>system.  That's the whole reason the standard management models like DMTF's
>CIM exist.
>
>On the other hand, I could very well see some of the _values_ for some of
>the metadata coming from externally source locations: like locale
>translatable descriptions/attributes.
>
>Keith
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Rob Harrop
>Sent: Monday, November 29, 2004 12:31 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Spring JMX Query
>
>Keith,
>
>I understand what you are aiming at with this approach and I think it 
>may be worthwhile me putting together an assembler based on this 
>approach, the only problem it doesn't solve is allowing for mgmt 
>interface to be modified without modifying the code. I have a question 
>though. You mentioned sharing the MBeanInfo objects to serve multiple 
>different managed resources. I don't know if this would work since the 
>MBeanInfo is used to store a lot of instance specific data such as 
>default values and cached data. If you were to share MBeanInfo instance 
>you would end up with the cached values colliding.
>
>Rob
>
>Keith Donald wrote:
>
>  
>
>>>As for defining the mgmt interface in code - aren't 
>>>we getting into the realms of recreating what JMX does already?
>>>   
>>>
>>>      
>>>
>>No, JMX employs different strategies for getting to the same thing; that
>>    
>>
>is,
>  
>
>>a configured management descriptor (MBeanInfo) describing a manageable
>>object.
>>
>>As you know, one of these strategies is reflection: you have your bean
>>implement a "*MBean" interface and JMX uses reflection to generate a new
>>MBeanInfo descriptor when your bean is registered with the MBeanServer.
>>    
>>
>But
>  
>
>>this has limitations: there is only so much you can find out from
>>reflection.  And MBeanInfos are not shared.
>>
>>Another strategy involves creating populated MBeanInfo instances ahead of
>>time, to support dynamic mbeans and model mbeans.  You specify the
>>descriptor separately and at runtime a DynamicMBean or RequiredModelMBean
>>proxy connects the descriptor with the managed bean instance.  In these
>>cases you're not required to define a strongly typed management interface
>>    
>>
>at
>  
>
>>all.
>>
>>I prefer strongly typed POJO management interfaces combined with
>>descriptive, configurable management metadata that can be shared between
>>POJO implementations that are of the same _logical type_.  For example,
>>let's say we have a logical type, like the JSR-77 "Service".  Such a type
>>can be expressed via a POJO management interface -- Service --, with
>>    
>>
>methods
>  
>
>>like start(), and stop().  Such an interface might also extend a base
>>management interface used by all managed entities, like
>>"ManagedSystemElement".
>>
>>In this example, I'd prefer my POJOs to implement Service, and I'd prefer
>>    
>>
>to
>  
>
>>have a shared "Service MBeanInfo" instance providing metadata about the
>>attributes, operations, and notifications instrumented by all services.  At
>>runtime, I'd expect my MBean adapter to note my bean is a "Service" and
>>locate the right MBeanInfo descriptor for registration in an MBeanServer as
>>a ModelMBean.
>>
>>One way of providing MBeanInfo information is XML, but I'd just assume have
>>it defined in java-code using annotations---cutting out the need for
>>reflection.
>>
>>My only caveat with such a solution is many times you want a much more
>>generically typed management model exposed to _clients_: e.g with strings,
>>primitives, object names, and generic tabular/composite data structure
>>    
>>
>types
>  
>
>>ONLY, while the _interal_ workings of your managed beans want a richly
>>    
>>
>typed
>  
>
>>model to work with.  This is because you can't often make the assumption
>>    
>>
>all
>  
>
>>your management clients have access to your classes, or that they're even
>>all java.  So I can see a need for our JMX support to create translators
>>that map between a richly typed model to a more generic management model.
>>
>>Keith
>>
>>
>>Keith
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On Behalf Of
>>Rob Harrop
>>Sent: Monday, November 29, 2004 11:44 AM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Spring JMX Query
>>
>>Keith,
>>
>>I have a passing familiarity with Commons Modeler and I understand what 
>>you mean about the inheritance. However, it should be more than possible 
>>to allow for mgmt interface inheritance using XML - there is no reason 
>>it couldn't be done. As for defining the mgmt interface in code - aren't 
>>we getting into the realms of recreating what JMX does already? Add to 
>>that I'm not sure how all the different metadata utils such as Commons 
>>Attributes handle inheritance - I'll need to check that out.
>>
>>Rob
>>
>>Keith Donald wrote:
>>
>> 
>>
>>    
>>
>>>Rob,
>>>
>>>Commons-modeler has such a format for defining model mbean metadata in
>>>      
>>>
>XML,
>  
>
>>>and an associated Registry allowing MBeanInfo definitions to be indexed by
>>>'type' (essentially a logical management class identifier) and shared
>>>between different MBean instances (perhaps backed by different POJO
>>>implementations.)
>>>
>>>In my experience where the format breaks down is with MBean inheritance.
>>>   
>>>
>>>      
>>>
>>It
>> 
>>
>>    
>>
>>>would extremely helpful if you could define base management interfaces
>>>      
>>>
>with
>  
>
>>>metadata and be able to extend to derive more specific management types.
>>>For anyone whose ever done any network management work, this is important.
>>>Look at JSR-77, it's basically defines a management hierarchy as well.
>>>
>>>Do we have the ability to define management interfaces in java code (with
>>>   
>>>
>>>      
>>>
>>an
>> 
>>
>>    
>>
>>>inheritance hierarchy), markup those interfaces with management metadata,
>>>and generate corresponding MBeanInfos at runtime that can be shared?  I
>>>wonder if that would work.  I'd much rather apply attributes to the
>>>management interfaces than the managed beans themselves...
>>>
>>>Keith
>>>
>>>-----Original Message-----
>>>From: spr...@li...
>>>[mailto:spr...@li...] On Behalf
>>>      
>>>
>Of
>  
>
>>>Rob Harrop
>>>Sent: Monday, November 29, 2004 11:18 AM
>>>To: spr...@li...
>>>Subject: [Springframework-developer] Spring JMX Query
>>>
>>>All,
>>>
>>>I have raised a new issue on JIRA related to Spring JMX and I would like 
>>>your input:
>>>      
>>>
>http://opensource.atlassian.com/projects/spring/browse/SPR-498.
>  
>
>>>Rob
>>>
>>>
>>>-------------------------------------------------------
>>>SF email is sponsored by - The IT Product Guide
>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>Discover which products truly live up to the hype. Start reading now. 
>>>http://productguide.itmanagersjournal.com/
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>SF email is sponsored by - The IT Product Guide
>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>Discover which products truly live up to the hype. Start reading now. 
>>>http://productguide.itmanagersjournal.com/
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now. 
>>http://productguide.itmanagersjournal.com/
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now. 
>>http://productguide.itmanagersjournal.com/
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>> 
>>
>>    
>>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>