cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources‏
Date Tue, 26 Apr 2011 05:56:33 GMT
As a heavy user of CXF, Spring, and wanting to leverage JMX more than we
have in the past, one thing you might want to consider is using Spring's
built in support for configuring and manipulating JMX MBeans[1].  If you run
under a servlet container like Tomcat that already provides a JMX
registry[2], life is very simple -- you can define your MBean beans,
attributes, and operations with Spring-provided annotations and all of the
wiring happens for you.  If not using Tomcat, then Spring still provides
easy mechanisms to integrate with any provided MBean server.

If the built in Spring support for JMX meets your requirements, it can save
you a *lot* of effort working on the plumbing, which would in turn let you
focus on the most important issues -- what MBeans, attributes, and
operations should be exposed, and what security controls need to be put in
place to determine what information the MBeans provide to whom, and what
state changes that they can create.

I very much look forward to seeing your progress on this project!

Craig McClanahan

[1]
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/jmx.html
<http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/jmx.html>
[2] http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html

2011/4/25 Shenglin Qiu <dabaipang@hotmail.com>

>
> Hi Sergey:
>
> I pasted your comments with font 10 along with mine with font 12, hope you
> don't mind :)
>
> > On Mon, Apr 25, 2011 at 12:25 AM, Travis Roy <dabaipang@hotmail.com>
> wrote:
> > >
> > > Hi Sergey:
> > > I have made some progress according to your last email, due to the size
> of
> > > each file, I have to paste some of them below. As you can see, in my
> spring
> > > application context, I deployed 2 testing Jax Rs services,
> UserServiceImpl
> > > and CustomerServiceImpl, and then I attached my JmxService in each of
> those
> > > 2 services, plus, I manually make these 2 services share the same root
> path.
> > >
> > > Besides listing all mbeans in
> > >  http://localhost:8080/cxfservice/jaxrs/jmx/list,  I now can add these
> in
> > > the URL:
> > >
> http://localhost:8080/cxfservice/jaxrs/jmx/component/org.apache.cxf:type=Bus.Service.Endpoint,*
> > >
> http://localhost:8080/cxfservice/jaxrs/jmx/component/org.apache.cxf:type=*,*
> > > http://localhost:8080/cxfservice/jaxrs/jmx/component/*:bus.id=*,*
> >
> > Very good
> >
> > > I think I need to get on IRC with you some time, and of course, at
> anytime
> > > when you are free.
> >
> > Most of the time I'm on #cxf (not today, we have a bank holiday) -
> > please join whenever you get some time.
> > Ping me privately please about your preferred times.
> >
> > > Sadly sometimes, after coding for some while, I lost the ideas of what
> I am
> > > doing and what I need to do. Such as, if I use Jconsole to monitor
> local
> > > java instance with mbeans exposed, for example, my local jetty, it can
> also
> > > show up a lot of interesting stuff, like memory usage and cpu usage in
> real
> > > time. But right now, except showing up the definitions of each mbean, I
> > > can't see anything more, and I am not also sure about whether I have
> shown
> > > the right mbeans and the right url path you wanted.
> >
> > Thanks for sharing those thoughts. The number of CXF MBeans is limited
> > indeed, but the goal of this project
> > is to make sure JMX MBeans are exposed properly over HTTP, so that
> > that can be accessed easily and presented in a number of formats. If
> > we do it right then in principle we can use the JAX-RS resource you
> > are working upon for exposing even non CXF MBeans, may be Karaf
> > Mbeans, etc, we'll see. Another goal of the project is to try to
> > enhance the existing LogBrowser WebUI, make it a bit richer.
> >
> Gwt, I would love to do it.
>
> > Here are some more technical comments, it might not be easy to trace
> > them if get them inlined in the copied beans.xml and files...
> >
> > - What you may want to do is to update InstrumentationManagerImpl to
> > be able to access the underlying MBeanServerConnection and have
> > InstrumentationManagerImpl inject into your JAX-RS resource, thus
> > letting the manager deal with JMS-specific configuration and
> > connection management - please do it a bit later on - not critical
> > right now
> >
>
> Because InstrumentationManagerImpl has an MBServerConnectorFactory which is
> focusing on create/stop/... an mbean server, adding MBeanServerConnection
> would make this class also have a client manager function, it's great! I
> will strictly follow your designs, as I can see it's one of the core in
> cxf-rs.
>
> > - Note that users may use JAX-RS only, JAX-WS only, or JAX-RS and
> > JAX-WS endpoints. Assume JAX-RS endpoints have only single root
> > resources for now. The JAX-RS resource you are working upon should
> > work either way. You can't have it added to JAX-WS endpoint, so it
> > should be independent. Also I think it should be able to return the
> > list of endpoints it 'manages', possibly in the form of expanded
> > QNames and list all MBeans which 'belong' to a specific endpoint only.
> >
>
> Yes, I should only focus on Jax-RS.
> And further Restful returnings, I have things like this, forgot to include
> this at last email.:
> URL:
>
> http://localhost:8080/cxfservice/jaxrs/jmx/component/org.apache.cxf:type=*,*
> Return (Forgive me about the poor xml format)
> <CxfMBeanCollection>
>        <CxfMBeans>
>             <CxfMBean>
>                   <canonicalName>
>                       org.apache.cxf:bus.id
> =cxf2006079,port="CustomerServiceImpl",service="{
> http://impl.service.ws.plumchoice.com/}CustomerServiceImpl
> ",type=Bus.Service.Endpoint
>                   </canonicalName>
>                   <domain>org.apache.cxf</domain>
>             </CxfMBean>
>
>             <CxfMBean>
>                 <canonicalName>
>                       org.apache.cxf:bus.id=cxf2006079,type=Bus
>                 </canonicalName>
>                 <domain>org.apache.cxf</domain>
>            </CxfMBean>
>
>           <CxfMBean>
>                 <canonicalName>
>                          org.apache.cxf:bus.id
> =cxf2006079,port="UserServiceImpl",service="{
> http://impl.service.ws.plumchoice.com/}UserServiceImpl
> ",type=Bus.Service.Endpoint
>                 </canonicalName>
>                 <domain>org.apache.cxf</domain>
>           </CxfMBean>
>       </CxfMBeans>
> </CxfMBeanCollection>
>
> > Not sure right now how this JAX-RS server can know about individual
> > endpoints - may be it should have a Bus injected, and the list of
> > expanded QNames, ex, {http://users}UserService, or
> > {http://customers}CustomerService. The server will return to the
> > clients this list: it will let them know it manages
> > {http://users}UserService and {http://customers}CustomerService. This
> > will work for JAX-RS endpoints with multiple root resources too. Next
> > clients will ask for a list of MBeans 'belonging' to say
> > {http://users}UserService. The server will return all MBeans which has
> > something to do with it, including a Bus MBean (which can be relevant
> > to other endpoints too) and Mbeans specific to/scoped by
> > {http://users}UserService.
> >
> Actually, I guess there are 2 places to differentiate each of Jax-rs
> services, which could satisfy the fact that individual endpoint can manage
> its own mbeans,
> First is do something in xml, but I have looked around it, and I find it is
> literally the core in cxf-rs,  thus very difficult to 'hack in' this
> configuration.
>     <jaxrs:server id="userServiceRs" address="/jaxrs">
>        <jaxrs:serviceBeans>
>            <ref bean="userService" />
>            <ref bean="jmxService" />
>        </jaxrs:serviceBeans>
>        <jaxrs:extensionMappings>
>            <entry key="feed" value="application/atom+xml"/>
>            <entry key="json" value="application/json"/>
>            <entry key="xml" value="application/xml"/>
>            <entry key="html" value="text/html"/>
>        </jaxrs:extensionMappings>
>         <jaxrs:jmx>
>                <jaxrs:bus>cxf</jaxrs:bus>
>
>  <jaxrs:url>service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi<jaxrs:url>
>         </jaxrs:jms>
>    </jaxrs:server>
>
> Pros are fine integration with spring and neat, Cons are about the
> difficulties in implementation.
>
> Second is modify the service bean itself to make it looks like:
> <bean id="userService"
> class="com.plumchoice.ws.service.impl.UserServiceImpl">
>         <property name="bus" ref="cxf" />
>         <property name="JMXServiceURL"
> value="service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
> </bean>
> This is referenced in
> cxf-rt-management/src/test/resources/managed-spring.xml, and my idea is let
> each jax-rs service bean to construct its InstrumentationManagerImpl
> internally:
>   <bean id="org.apache.cxf.management.InstrumentationManager"
> class="org.apache.cxf.management.jmx.InstrumentationManagerImpl">
>         <property name="bus" ref="cxf" />
>        <property name="enabled" value="true"/>
>         <property name="threaded" value="false"/>
>        <property name="daemon" value="false"/>
>         <property name="JMXServiceURL"
> value="service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
>    </bean>
> Pros: basic spring context, ease the configuration/implementation compared
> to 1, Cons: a little amateur compared to 1?
>
>
> > Does it make sense ? What do you think ?
> >
> Due to the large size of cxf, I will follow the steps from you. My thoughts
> could be deviated, so please correct me at any time.
>
> Your mentoring has delighted me since the beginning and it's awesome that I
> have received that confirmation email from google today that I am enrolled.
> Thank you very much.
>
> Regards:
> Shenglin Qiu
>
>
>
>
> > Does it make sense ? What do you think ?
> >
> Due to the large size of cxf, I will follow the steps from you. My thoughts
> could be deviated, so please correct me at any time.
>
> Your mentoring has delighted me since the beginning and it's awesome that I
> have received that confirmation email from google today that I am enrolled.
> Thank you very much.
>
>
>
> > Date: Mon, 25 Apr 2011 16:21:14 +0100
> > Subject: Re: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as
> the JAX-RS resources‏
> > From: sberyozkin@gmail.com
> > To: dabaipang@hotmail.com
> > CC: dev@cxf.apache.org
> >
> > Hi Shenglin
> >
> > You are progressing very well, please see comments inline
> >
> > On Mon, Apr 25, 2011 at 12:25 AM, Travis Roy <dabaipang@hotmail.com>
> wrote:
> > >
> > > Hi Sergey:
> > > I have made some progress according to your last email, due to the size
> of
> > > each file, I have to paste some of them below. As you can see, in my
> spring
> > > application context, I deployed 2 testing Jax Rs services,
> UserServiceImpl
> > > and CustomerServiceImpl, and then I attached my JmxService in each of
> those
> > > 2 services, plus, I manually make these 2 services share the same root
> path.
> > >
> > > Besides listing all mbeans in
> > >  http://localhost:8080/cxfservice/jaxrs/jmx/list,  I now can add these
> in
> > > the URL:
> > >
> http://localhost:8080/cxfservice/jaxrs/jmx/component/org.apache.cxf:type=Bus.Service.Endpoint,*
> > >
> http://localhost:8080/cxfservice/jaxrs/jmx/component/org.apache.cxf:type=*,*
> > > http://localhost:8080/cxfservice/jaxrs/jmx/component/*:bus.id=*,*
> >
> > Very good
> >
> > > I think I need to get on IRC with you some time, and of course, at
> anytime
> > > when you are free.
> >
> > Most of the time I'm on #cxf (not today, we have a bank holiday) -
> > please join whenever you get some time.
> > Ping me privately please about your preferred times.
> >
> > > Sadly sometimes, after coding for some while, I lost the ideas of what
> I am
> > > doing and what I need to do. Such as, if I use Jconsole to monitor
> local
> > > java instance with mbeans exposed, for example, my local jetty, it can
> also
> > > show up a lot of interesting stuff, like memory usage and cpu usage in
> real
> > > time. But right now, except showing up the definitions of each mbean, I
> > > can't see anything more, and I am not also sure about whether I have
> shown
> > > the right mbeans and the right url path you wanted.
> >
> > Thanks for sharing those thoughts. The number of CXF MBeans is limited
> > indeed, but the goal of this project
> > is to make sure JMX MBeans are exposed properly over HTTP, so that
> > that can be accessed easily and presented in a  number of formats. If
> > we do it right then in principle we can use the JAX-RS resource you
> > are working upon for exposing even non CXF MBeans, may be Karaf
> > Mbeans, etc, we'll see. Another goal of the project is to try to
> > enhance the existing LogBrowser WebUI, make it a bit richer.
> >
> > Here are some more technical comments, it might not be easy to trace
> > them if get them inlined in the copied beans.xml and files...
> >
> > - What you may want to do is to update InstrumentationManagerImpl to
> > be able to access the underlying MBeanServerConnection and have
> > InstrumentationManagerImpl inject into your JAX-RS resource, thus
> > letting the manager deal with JMS-specific configuration and
> > connection management  - please do it a bit later on - not critical
> > right now
> >
> > - Note that users may use JAX-RS only, JAX-WS only, or JAX-RS and
> > JAX-WS endpoints. Assume JAX-RS endpoints have only single root
> > resources for now. The JAX-RS resource you are working upon should
> > work either way. You can't have it added to JAX-WS endpoint, so it
> > should be independent. Also I think it should be able to return the
> > list of endpoints it 'manages', possibly in the form of expanded
> > QNames and list all MBeans which 'belong' to a specific endpoint only.
> >
> > Not sure right now how this JAX-RS server can know about individual
> > endpoints - may be it should have a Bus injected, and the list of
> > expanded QNames, ex, {http://users}UserService, or
> > {http://customers}CustomerService. The server will return to the
> > clients this list: it will let them know it manages
> > {http://users}UserService and  {http://customers}CustomerService. This
> > will work for JAX-RS endpoints with multiple root resources too. Next
> > clients will ask for a list of MBeans 'belonging' to say
> > {http://users}UserService. The server will return all MBeans which has
> > something to do with it, including a Bus MBean (which can be relevant
> > to other endpoints too) and Mbeans specific to/scoped by
> > {http://users}UserService.
> >
> > Does it make sense ? What do you think ?
> >
> > Cheers, Sergey
> >
> >
> >
> > >
> > > Thank you very much.
> > > Regards:
> > > Shenglin Qiu
> > >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message