cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shenglin Qiu <dabaip...@hotmail.com>
Subject RE: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources‏
Date Tue, 26 Apr 2011 05:10:48 GMT

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