Hi Shenglin You are progressing very well, please see comments inline
On Mon, Apr 25, 2011 at 12:25 AM, Travis Roy <[email protected]> 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 >
