Re: [Springframework-developer] Spring JMX Query

[Rob H. <ro...@ca...>]

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
>
>
>  
>