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 <dabaip...@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: sberyoz...@gmail.com > To: dabaip...@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 <dabaip...@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 > >
