You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Benson Margulies <bi...@gmail.com> on 2011/02/09 17:08:41 UTC
MBeans, get your MBeans
CXF, like many other things at Apache and beyond, exposes various
management information via MBeans. I'm extremely curious as to how
people consume them.
I looked around, and found no live open source alternatives. There's
always jconsole, but it's quite minimal, and remote access is hell to
organize.
I'm considering tasking someone to build a sort of JSON<->MBean
gateway, and then an HTML UI. On the one hand, has any reader already
solved this problem? On the other hand, is anyone interested in
setting up shop to build this out as an open source project?
Re: MBeans, get your MBeans
Posted by Johan Edstrom <jo...@acj-consulting.com>.
Most organizations would simply use something like
Nagios, OpenNMS, Zenoss, Tivoli, OpenView and so on where you
define JMX counter monitoring, what is monitored tend to be what affects production.
Like enqueue/dequeue /s
Or number of threads / JVM memory usage in a webapp.
On Feb 9, 2011, at 9:08 AM, Benson Margulies wrote:
> CXF, like many other things at Apache and beyond, exposes various
> management information via MBeans. I'm extremely curious as to how
> people consume them.
>
> I looked around, and found no live open source alternatives. There's
> always jconsole, but it's quite minimal, and remote access is hell to
> organize.
>
> I'm considering tasking someone to build a sort of JSON<->MBean
> gateway, and then an HTML UI. On the one hand, has any reader already
> solved this problem? On the other hand, is anyone interested in
> setting up shop to build this out as an open source project?
Re: Enable MTOM for a specific method
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 09 February 2011 1:24:24 pm Hardeep Singh wrote:
> Hi,
>
> Is it possible to enabled MTOM for only a specific method in the Web
> Service?
>
> I am using this way to enable MTOM.
>
> JaxWsServerFactoryBean factory = new JaxWsServerFactoryBean();
> Map<String, Object> mtomProperty = new HashMap<String, Object>();
> mtomProperty.put("mtom-enabled", Boolean.TRUE);
> factory.setProperties(mtomProperty);
>
> This enables it for all the methods, changes the content-type, adds message
> boundaries etc. Please let me know if this cannot be done.
The only way this could be done would be to add an interceptor at the very
start of the OUT chain that would look at the operation and set the "mtom-
enabled", Boolean.TRUE flag on the message just like above.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Enable MTOM for a specific method
Posted by Hardeep Singh <ha...@pelco.com>.
Hi,
Is it possible to enabled MTOM for only a specific method in the Web
Service?
I am using this way to enable MTOM.
JaxWsServerFactoryBean factory = new JaxWsServerFactoryBean();
Map<String, Object> mtomProperty = new HashMap<String, Object>();
mtomProperty.put("mtom-enabled", Boolean.TRUE);
factory.setProperties(mtomProperty);
This enables it for all the methods, changes the content-type, adds message
boundaries etc. Please let me know if this cannot be done.
Thanks
Hardeep Singh
This transmission is intended only for use by the intended
recipient(s). If you are not an intended recipient you should not read, disclose copy, circulate or in any other way use the information contained in this transmission. The information contained in this transmission may be confidential and/or privileged. If you have received this transmission in error, please notify the sender immediately and delete this transmission including any attachments.
Re: MBeans, get your MBeans
Posted by Sergey Beryozkin <sb...@gmail.com>.
I hope that we will also get a chance to extend the LogBrowser (in
rt/management-web) and turn into a management browser.
Left hand pane: list of endpoints
Right hand pane: split into two tabs, left tab - is the list of log
records for a selected endpoint, right one - management statistics
collected from PersistIn/OutInterceptors (from the rt/management)...
Cheers, Sergey
On Wed, Feb 9, 2011 at 4:19 PM, antoine philippe chaker
<ph...@gmail.com> wrote:
> Please, what do you mean by "to build a sort of JSON<->MBean, and then an
> HTML UI" ?
>
> 2011/2/9 Benson Margulies <bi...@gmail.com>
>
>> CXF, like many other things at Apache and beyond, exposes various
>> management information via MBeans. I'm extremely curious as to how
>> people consume them.
>>
>> I looked around, and found no live open source alternatives. There's
>> always jconsole, but it's quite minimal, and remote access is hell to
>> organize.
>>
>> I'm considering tasking someone to build a sort of JSON<->MBean
>> gateway, and then an HTML UI. On the one hand, has any reader already
>> solved this problem? On the other hand, is anyone interested in
>> setting up shop to build this out as an open source project?
>>
>
>
>
> --
> *CHAKER Antoine Philippe Chekry*
> *Ingénieur en Informatique*
> *Développeur Java J2EE **,
> <http://www.blackbeltfactory.com/ui#!User/aphilippe>WebMaster*
> *CNPS - Cote d'Ivoire*
> *
> *
>
Re: MBeans, get your MBeans
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Benson
On Wed, Feb 9, 2011 at 7:06 PM, Benson Margulies <bi...@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.
>
Interesting. Something similar to what we have thought about before,
back in the old days.
Similarly to the unified search experience, one can offer a unified
management experience, whereby every
important resource supports a _manage query extension and return an
HTML form/etc allowing for viewing the statistics and do some more
involved tasks.
As far as I recall we briefly discussed it on the dev list with some
concerns being expressed about the possible complexity associated with
the accurate representation of the management data. The idea at a time
was to introduce a JAX-RS wrapper (in rt/management-web) which would
sit on top of MBeans.
> One of my colleagues is likely to post some more specific thoughts
> about what he hates about the MBean API.
>
Cool :-)
Cheers, Sergey
Re: MBeans, get your MBeans
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Benson
On Thu, Feb 10, 2011 at 10:28 PM, Benson Margulies
<bi...@gmail.com> wrote:
> 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.
Sure, makes sense. Just wondering, would this CXF JAX-RS Resource be
able to act as the wrapper for local CXF endpoint's MBeans but also as
a top-level wrapper (something you are thinking of) for all the other
MBeans/producers of MBeans ? I guess it will depend on the way this
would be resource discover the MBeans locally. It was awhile since I
did the JMX work, but from the JMX consumer's point of view, it's
probably RMI for the remote access and local calls for other cases,
but the MBeans discovery code inside this resource should be the
unchanged...
Cheers, Sergey
>
>
> On Thu, Feb 10, 2011 at 5:12 PM, Sergey Beryozkin <sb...@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 <jc...@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 <ih...@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 <bi...@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 <bi...@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.
>>>>>>
>>>>>
>>>>
>>>
>>
>
RE: MBeans, get your MBeans
Posted by Jason Chaffee <jc...@ebates.com>.
I think that makes a lot sense Sergey. I think it could help.
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
Sent: Thursday, February 10, 2011 2:49 PM
To: users@cxf.apache.org
Subject: Re: MBeans, get your MBeans
Hi
On Thu, Feb 10, 2011 at 10:34 PM, Jason Chaffee <jc...@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 <sb...@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 <jc...@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 <ih...@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 <bi...@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 <bi...@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.
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: MBeans, get your MBeans
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On Thu, Feb 10, 2011 at 10:34 PM, Jason Chaffee <jc...@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 <sb...@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 <jc...@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 <ih...@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 <bi...@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 <bi...@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.
>>>>>>
>>>>>
>>>>
>>>
>>
>
RE: MBeans, get your MBeans
Posted by Jason Chaffee <jc...@ebates.com>.
One thing I would personally change aobut the URI's in Jean-Francios impl.
From:
http://curcuma:9999/rest/jmx/notifications
http://curcuma:9999/rest/jmx/
TO:
http://curcuma:9999/jmx/notifications
http://curcuma:9999/jmx/
Not sure why the "rest" noun is needed.
Jason
-----Original Message-----
From: Jason Chaffee [mailto:jchaffee@ebates.com]
Sent: Thursday, February 10, 2011 3:16 PM
To: users@cxf.apache.org
Subject: RE: MBeans, get your MBeans
I think Jean-Francois does a fairly good job of this, but I will give a bullet point of what I think is important.
Btw, I found a second post from Jean-Francios that has other stuff implemented as well.
http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation1
- Should be truly RESTful, where the http verbs matter on the same URI/resource, etc.
- Should support GET, POST/PUT.
- Ability to support listing of MBeans
- Ability to use the query mechanisms in JMX with ObjectNames.
- Ability to do notifications
- Ability to only get only specific method values form the MBean instead of all. This is important for monitoring purposes with something like Nagios.
Jason
-----Original Message-----
From: Benson Margulies [mailto:bimargulies@gmail.com]
Sent: Thursday, February 10, 2011 2:51 PM
To: users@cxf.apache.org
Subject: Re: MBeans, get your MBeans
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 <jc...@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
>
> 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: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 <sb...@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 <jc...@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 <ih...@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 <bi...@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 <bi...@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.
>>>>>>
>>>>>
>>>>
>>>
>>
>
RE: MBeans, get your MBeans
Posted by Jason Chaffee <jc...@ebates.com>.
I think Jean-Francois does a fairly good job of this, but I will give a bullet point of what I think is important.
Btw, I found a second post from Jean-Francios that has other stuff implemented as well.
http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation1
- Should be truly RESTful, where the http verbs matter on the same URI/resource, etc.
- Should support GET, POST/PUT.
- Ability to support listing of MBeans
- Ability to use the query mechanisms in JMX with ObjectNames.
- Ability to do notifications
- Ability to only get only specific method values form the MBean instead of all. This is important for monitoring purposes with something like Nagios.
Jason
-----Original Message-----
From: Benson Margulies [mailto:bimargulies@gmail.com]
Sent: Thursday, February 10, 2011 2:51 PM
To: users@cxf.apache.org
Subject: Re: MBeans, get your MBeans
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 <jc...@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
>
> 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: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 <sb...@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 <jc...@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 <ih...@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 <bi...@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 <bi...@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.
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: MBeans, get your MBeans
Posted by Benson Margulies <bi...@gmail.com>.
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 <jc...@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
>
> 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: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 <sb...@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 <jc...@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 <ih...@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 <bi...@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 <bi...@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.
>>>>>>
>>>>>
>>>>
>>>
>>
>
RE: MBeans, get your MBeans
Posted by Jason Chaffee <jc...@ebates.com>.
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: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 <sb...@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 <jc...@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 <ih...@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 <bi...@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 <bi...@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.
>>>>>
>>>>
>>>
>>
>
Re: MBeans, get your MBeans
Posted by Benson Margulies <bi...@gmail.com>.
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 <sb...@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 <jc...@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 <ih...@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 <bi...@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 <bi...@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.
>>>>>
>>>>
>>>
>>
>
Re: MBeans, get your MBeans
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <jc...@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 <ih...@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 <bi...@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 <bi...@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.
>>>>
>>>
>>
>
RE: MBeans, get your MBeans
Posted by Jason Chaffee <jc...@ebates.com>.
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 <ih...@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 <bi...@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 <bi...@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.
>>>
>>
>
RE: MBeans, get your MBeans
Posted by Jason Chaffee <jc...@ebates.com>.
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 <ih...@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 <bi...@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 <bi...@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.
>>>
>>
>
Re: MBeans, get your MBeans
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On Wed, Feb 9, 2011 at 8:53 PM, Ian Helmke <ih...@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 <bi...@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 <bi...@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.
>>>
>>
>
Re: MBeans, get your MBeans
Posted by Ian Helmke <ih...@gmail.com>.
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 <bi...@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 <bi...@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.
>>
>
Re: MBeans, get your MBeans
Posted by Benson Margulies <bi...@gmail.com>.
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 <bi...@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.
>
Re: MBeans, get your MBeans
Posted by Benson Margulies <bi...@gmail.com>.
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.
Re: MBeans, get your MBeans
Posted by antoine philippe chaker <ph...@gmail.com>.
Please, what do you mean by "to build a sort of JSON<->MBean, and then an
HTML UI" ?
2011/2/9 Benson Margulies <bi...@gmail.com>
> CXF, like many other things at Apache and beyond, exposes various
> management information via MBeans. I'm extremely curious as to how
> people consume them.
>
> I looked around, and found no live open source alternatives. There's
> always jconsole, but it's quite minimal, and remote access is hell to
> organize.
>
> I'm considering tasking someone to build a sort of JSON<->MBean
> gateway, and then an HTML UI. On the one hand, has any reader already
> solved this problem? On the other hand, is anyone interested in
> setting up shop to build this out as an open source project?
>
--
*CHAKER Antoine Philippe Chekry*
*Ingénieur en Informatique*
*Développeur Java J2EE **,
<http://www.blackbeltfactory.com/ui#!User/aphilippe>WebMaster*
*CNPS - Cote d'Ivoire*
*
*