Hi On Thu, Feb 10, 2011 at 10: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
ok > > 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. > If CXF supported the approach which you reckon is the best one, then may be it would contribute somehow to the idea of standardizing the RESTful interface. I'm wondering, would it be a good project idea for the GSOC 2011 ? Cheers, Sergey > 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. >>>>>> >>>>> >>>> >>> >> >
