Basically what this boils down to is that we'd like to generate some MBeans to define our management interface, and create a web front-end for them - that way we have a nice interface for ourselves but we also allow for others to use whatever MBeans management interface they want (which is ideal if they're using something else already to manage other MBean-managed java software). The issue is that the MBeans API seems primarily reflective and from what I've been able to glean from reading up on it, it would take an equal or lesser amount of work to create a generic JSON -> MBean interface and a web front-end that way vs. crafting a custom, software-specific solution.
One could imagine running a small java/JAX-RS program locally on any machine with MBeans to monitor which exposes some kind of JSON -> MBean API, which a web front-end could then query and present interesting information from. On Wed, Feb 9, 2011 at 2:58 PM, Benson Margulies <[email protected]> wrote: > Ian is now prepared to correct my slightly warped presentation of our > motivation, as soon as I send this for him to reply to. > > > On Wed, Feb 9, 2011 at 2:06 PM, Benson Margulies <[email protected]> > wrote: >> The MBean client API is kind of a pain in the neck. Talking RMI to >> contact MBean servers on multiple machines is a really big pain in the >> neck. >> >> If you were sitting down to create a webapp to visualize some >> management data, you would perhaps rather write that code in terms of >> a JSON-ish data model of the data. than in terms of the MBean API. >> >> So, our thought was to solve both problems: get rid of the RMI >> business by having a service on each machine that exposed the data via >> JAX-RS, and be able to code to a less annoying data model. >> >> One of my colleagues is likely to post some more specific thoughts >> about what he hates about the MBean API. >> >
