cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: MBeans, get your MBeans
Date Thu, 10 Feb 2011 22:48:38 GMT
Hi

On Thu, Feb 10, 2011 at 10:34 PM, Jason Chaffee <jchaffee@ebates.com> 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:bimargulies@gmail.com]
> Sent: Thursday, February 10, 2011 2:29 PM
> To: users@cxf.apache.org
> 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 <sberyozkin@gmail.com> 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 <jchaffee@ebates.com> wrote:
>>> Here is another one.
>>>
>>> http://www.jolokia.org/
>>>
>>> Jason
>>>
>>>
>>> -----Original Message-----
>>> From: Jason Chaffee [mailto:jchaffee@ebates.com]
>>> Sent: Wed 2/9/2011 2:48 PM
>>> To: users@cxf.apache.org; users@cxf.apache.org
>>> 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:sberyozkin@gmail.com]
>>> Sent: Wed 2/9/2011 1:58 PM
>>> To: users@cxf.apache.org
>>> Subject: Re: MBeans, get your MBeans
>>>
>>> Hi
>>>
>>> On Wed, Feb 9, 2011 at 8:53 PM, Ian Helmke <ihelmke@gmail.com> 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 <bimargulies@gmail.com>
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 <bimargulies@gmail.com>
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.
>>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
View raw message