Menu
▾
▴
Re: [Springframework-developer] Spring JMX Query
|
From: Rob H. <ro...@ca...> - 2004-11-29 17:51:31
|
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 > > > > |
