Jason, Yes, we looked at these and saw what you saw. So, we wonder if we can nucleate just what you are talking about: a comprehensive, standardized approach.
--benson On Thu, Feb 10, 2011 at 5:34 PM, Jason Chaffee <[email protected]> wrote: > Which is what all the implementations that I sent out do. The best one, IMO, > is this one > > http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation > > It uses JAX-RS, but he never got around to implementing anything other than > GET. Jolokia has all the operations, but it isn't very RESTful as the URI's > are read/write/etc. Instead of using the same URI and HTTP verbs. > > Personally, I would really like to see someone standardize this. I know > someone was talking about a proposal to JCP for a RESTful interface JMX a > couple of years ago, not sure what ever happened to that. > > Jason > > -----Original Message----- > From: Benson Margulies [mailto:[email protected]] > Sent: Thursday, February 10, 2011 2:29 PM > To: [email protected] > Subject: Re: MBeans, get your MBeans > > Sergey, > > Ian & I are plotting a bigger-than-CXF solution here. Imagine a java > process. it uses the same trick as VisualVM to find all the local > producers of MBeans, consumes them all, and then exports the results > as JSON/Rest. CXF's beans should be just as magic with this as any > others. > > > On Thu, Feb 10, 2011 at 5:12 PM, Sergey Beryozkin <[email protected]> > wrote: >> Thanks for the links. Shipping a JAX-RS resource doing whatever >> mapping we agree upon between MBeans and HTML/JSON/XML seems >> promising. This resource can be deployed as part of the custom >> Application alongside with other root resources, and/or as a >> standalone JAX-RS application, when say JAX-WS endpoints are being >> managed. >> We would not even has to start embedding HTML views into the browser, >> this can be done later. Ultimately we can have many tabs, one for >> logs, one for MBean-based statistics and may be operations, one for >> showing the exchanges recorded with the help of >> PersistIn/OutInterceptors, etc... >> Benson, Ian, can it be of interest to you ? >> >> Cheers, Sergey >> >> On Wed, Feb 9, 2011 at 11:41 PM, Jason Chaffee <[email protected]> wrote: >>> Here is another one. >>> >>> http://www.jolokia.org/ >>> >>> Jason >>> >>> >>> -----Original Message----- >>> From: Jason Chaffee [mailto:[email protected]] >>> Sent: Wed 2/9/2011 2:48 PM >>> To: [email protected]; [email protected] >>> Subject: RE: MBeans, get your MBeans >>> >>> There are several people working on REST for JMX. See the links below. >>> >>> http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation >>> >>> http://esme.apache.org/jmx-rest-api.html >>> >>> http://code.google.com/p/polarrose-jmx-rest-bridge/ >>> >>> http://stackoverflow.com/questions/1571600/is-there-any-jmx-rest-bridge-available >>> >>> >>> Jason >>> >>> -----Original Message----- >>> From: Sergey Beryozkin [mailto:[email protected]] >>> Sent: Wed 2/9/2011 1:58 PM >>> To: [email protected] >>> Subject: Re: MBeans, get your MBeans >>> >>> Hi >>> >>> On Wed, Feb 9, 2011 at 8:53 PM, Ian Helmke <[email protected]> wrote: >>>> 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. >>>> >>> >>> What do you think about shipping a JAX-RS resource with say >>> @Path("/manage") in the rt/management-web ? >>> This resource can be deployed as a JAX-RS endpoint, in-process with >>> the CXF server and will be configured with the address(es) or ids of >>> jaxws/jaxrs endpoints. Internally it will connect to endpoint-specific >>> MBeans ? >>> >>> cheers, Sergey >>> >>>> 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. >>>>>> >>>>> >>>> >>> >> >
