RE: GSoC - CXF-3388
First, thank you very much, Daniel, your suggestions are very helpful for me to get things started. Proposal Title: Expose CXF JMX MBeans as the JAX-RS resources Student Name: Shenglin Apache registered account alias: Travis Student E-mail: dabaip...@hotmail.com IM: qslnewy...@yahoo.com Phone: please email and will reply with it. Project/Mission Description Original Description CXF-3388: The JAX-RS application exposing CXF JMX MBeans over HTTP needs to be added to the rt/management-web component. My Abstract: Add a web module with json or simple GET/POST string capability connecting to CXF inbound server, return CXF JMX MBean info and display it on web page. Proposal Timeline and Project Plan Before April 18(GSOC application deadline): * Join CXF discussion group with related engineers, mentors. * Learn the final goal of this project, what it could be like and what CXF engineers and mentors what it to be like. * Study CXF JMX MBean. * Discuss all necessary web approaches which could be used in this project, e.g. server technology: plain servlet, Spring MVC, JSF, GWT / web container, jetty, tomcat * Design the inbound server prototype which is with JMX MBean enabled. * Design the prototype of clients which is for testing purposes. * Discuss the look & feel in UI. April 18 – Before the official coding time: * Finalize the project plan and developing schedule which must include a review/qa session * Build inbound prototype from the discussion results and gain experiences on this JMX MBeans addon in CXF Official coding period starts: (If I was lucky enough to get enrolled) May - July * Coding * Keep in touching with relative CXF engineers, mentors, on design, and review. July - Aug * QA * Code review * Documentation. Personal Introduction I have been using Java for academic research and work for about 3 years. I am currently a computer engineering student, and have F1 visa in US. (Visa status: F1, expiration data: Aug 31, 2011, will have the chance to extend it to December 2011 if it's necessary). I have good experiences in using cxf for ws outbound call and good practices in inbound server. I think it's amazing if I could have this opportunity to make a further step. Please feel free to contact me for further questions. Note Above plans and ideas could be very 'junior', all suggestions, advices and helps are more than welcomed. Very appreciate anybody's reply at this moment. Regards: Shenglin Qiu 01/Apr/2011 > From: dk...@apache.org > To: dabaip...@hotmail.com > Subject: GSoC - CXF-3388 > Date: Fri, 1 Apr 2011 15:57:25 -0400 > > > I noticed you added a comment to CXF-3388 about possibly tackling that for > GSoC. > > My suggestion would be to send a note to dev@cxf.apache.org and introduce > yourself and start a discussion there about it. Part of the GSoC project > selection process is evaluating how well the student engaged the community in > creating the proposal. > > You'll need to start drafting a full project proposal and timeline, but > getting the community to help you with that would be the best bet. > > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog > Talend - http://www.talend.com
GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources
Proposal Title: Expose CXF JMX MBeans as the JAX-RS resources, CXF-3388 Student Name: Shenglin Apache registered account alias: Travis Student E-mail: dabaip...@hotmail.com IM: qslnewy...@yahoo.com Phone: please email and will reply with it. Project/Mission Description Original Description CXF-3388: The JAX-RS application exposing CXF JMX MBeans over HTTP needs to be added to the rt/management-web component. My Abstract: Add a web module with json or simple GET/POST string capability connecting to CXF inbound server, return CXF JMX MBean info and display it on web page. Please note: this is my initial understanding from the first round study, most probably, isn't mature, but I am 100% willing to take engineers and mentors' ideas. *Why This Project* I have been using Java, including core Java, Spring, Hibernate, Apache open sources, JSF, Struts2, Vaadin, GWT in projects both professionally and academically around 3-4 years, I have been using plain Javascript and Jquery professionally around 2 years. I am very comfortable with the projects based on Java and Javascript. Meanwhile, as a Java developer, I constantly involved in both front end and back end development, from my past experiences on https://boost.att.com, https://ct.att.com, http://www.key2world.com, http://www.bebeme.com, 2 major academic research projects(search engines' performance analysis) by core java, I have gained all kinds of development/research knowledge. In all my development memory, Apache open source is always the first dependency I need to add, it provides great tools, such as String checking, credit card info checking are the 2 used most frequently. CXF is the only one I would pick for light/middle weight web service development, I have studied CXF and Axis2, and I feel CXF offers way better development approach, in terms of modern JEE style, including the configuration xml style and integration with Spring. Apache Foundation is the first group I picked in GSoC, and when I see CXF, I feel so exited and it must be the one I have to try to join. Meanwhile, after reading GSoC application principles, I realize and understand the fact that this is not just for students who want to kill some time in summer, it's a serious project with clear approaches and goals, everyone must take their best efforts to get involved with. Therefore, I must wisely choose a GSoC project in Apache with my current knowledge pool and comfortable programming language, in terms of maximizing the chance to get enrolled. CXF-3388 fits perfectly with my target. Proposal Timeline and Project Plan Before April 18(GSOC application deadline): * Join CXF discussion group with related engineers, mentors. * Learn the final goal of this project, what it could be like and what CXF engineers and mentors what it to be like. * Study CXF JMX MBean. * Discuss all necessary web approaches which could be used in this project, e.g. server technology: plain servlet, Spring MVC, JSF, GWT / web container, jetty, tomcat * Design the inbound server prototype which is with JMX MBean enabled. * Design the prototype of clients which is for testing purposes. * Discuss the look & feel in UI. April 18 – Before the official coding time: * Finalize the project plan and developing schedule which must include a review/qa session * Build inbound prototype from the discussion results and gain experiences on this JMX MBeans addon in CXF Official coding period starts: (If I was lucky enough to get enrolled, this section will be significantly grown and detailed during the pre-step) May - July * Coding * Keep in touching with relative CXF engineers, mentors, on design, and review. July - Aug * QA * Code review * Documentation. Personal Introduction I have been using Java for academic research and work for about 3 years. I am currently a computer engineering student, and have F1 visa in US. (Visa status: F1, expiration data: Aug 31, 2011, will have the chance to extend it to December 2011 if it's necessary). Professional experiences: http://www.key2world.com Java developer http://www.bebeme.com .Net developer Academic experiences: Web data mining: explore the search ability of search engines (SUNY Binghamton University, Mar, 08 – May, 09) A meta-search engine for finding semiconductor devices (SUNY Binghamton University, Sep, 07 – Dec, 07) I have good experiences in using cxf for ws outbound call and good practices in inbound server. I think it's amazing if I could have this opportunity to make a further step. Please feel free to contact me for further questions. Note Above plans and ideas could be very 'junior', all suggestions, advices and helps are more than welcomed. Very appreciate anybody's reply at this moment. Regards: Shenglin Qiu 01/Apr/2011
RE: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources
Hi Sergey: I have submitted the proposal in GSoC site - Apache Software Foundation, title: CXF-3388 Expose CXF JMX MBeans as the JAX-RS resources. Please feel free to setup anytime for further mentoring. (607-727-3067)I have checked out the source code, compiled and imported in eclispe, local setup is done. Thank you. Shenglin Qiu Date: Thu, 7 Apr 2011 10:10:16 +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 Hi - that looks good, register it today please and then reply to the dev list confirming it I'd only add "* Check out svn http://svn.apache.org/repos/asf/cxf/trunk/rt/management/ and local dev environment setup 1. Setup a simple inbound cxf server, add InstrumentationManager into CXF bus config. 2. Use JConsole to monitor." into the second phase (ranking) Cheers, Sergey 2011/4/7 Shenglin Qiu Proposal Title: Expose CXF JMX MBeans as the JAX-RS resources Student Name: Shenglin Apache registered account alias: Travis Student E-mail: dabaip...@hotmail.com IM: qslnewy...@yahoo.com Phone: 607-727-3067 Project/Mission Description Original Description CXF-3388: The JAX-RS application exposing CXF JMX MBeans over HTTP needs to be added to the rt/management-web component. *Why This Project* I have been using Java, including core Java, Spring, Hibernate, Apache open sources, JSF, Struts2, Vaadin, GWT in projects both professionally and academically around 3-4 years, I have been using plain Javascript and Jquery professionally around 2 years. I am very comfortable with the projects based on Java and Javascript. Meanwhile, as a Java developer, I constantly involved in both front end and back end development, from my past experiences on https://boost.att.com, https://ct.att.com, http://www.key2world.com, http://www.bebeme.com, 2 major academic research projects(search engines' performance analysis) by core java, I have gained all kinds of development/research knowledge. In all my development memory, Apache open source is always the first dependency I need to add, it provides great tools, such as String checking, credit card info checking are the 2 used most frequently. CXF is the only one I would pick for light/middle weight web service development, I have studied CXF and Axis2, and I feel CXF offers way better development approach, in terms of modern JEE style, including the configuration xml style and integration with Spring. Apache Foundation is the first group I picked in GSoC, and when I see CXF, I feel so exited and it must be the one I have to try to join. Meanwhile, after reading GSoC application principles, I realize and understand the fact that this is not just for students who want to kill some time in summer, it's a serious project with clear approaches and goals, everyone must take their best efforts to get involved with. Therefore, I must wisely choose a GSoC project in Apache with my current knowledge pool and comfortable programming language, in terms of maximizing the chance to get enrolled. CXF-3388 fits perfectly with my target. Proposal Timeline and Project Plan (Revised) April 1 - Apr 8 (GSoC Application Deadline) * Contact with Sergey and all project involved staff. * Study CXF and JMX MBean server interaction. * Check out svn http://svn.apache.org/repos/asf/cxf/trunk/rt/management/ and local dev environment setup 1. Setup a simple inbound cxf server, add InstrumentationManager into CXF bus config. 2. Use JConsole to monitor. * Revise proposal and submit proposal to GSoC. April 8 - April 24 (Student Ranking/Scoring Deadline) * Code study http://svn.apache.org/repos/asf/cxf/trunk/rt/management/, and http://svn.apache.org/repos/asf/cxf/trunk/rt. * Discuss the project approach, including: data models, backend layers, complexity, 3388's configurations, integrations and settings with existing CXF RT, prototype building, testing methods and desired outputs. * Discuss the final data models, inputs/outputs which will be used for UI presentation. * Start to build snapshot version. April 24 – May 24 (Official Coding Start) * Build prototype from discussion, integrate into prototype inbound server and gain real experiences on this MBeans - CXF add-on -- Heavy coding. Official coding period starts: May 24 - July 11 (Mid-Term Evaluation Start) * Always keep in touch with mentor. * Coding CXF JMX MBeans exposure based on prototype. -- Heavy coding. * Integrate the coding to prototype server, use JConsole to check every step as debugging and testing. * Discuss, design all necessary web approaches which could be used in this project, e.g. server technology: plain servlet, Spring MVC, JSF, GWT / web container, jetty, tomcat * Start to build up front end, I assume some universal C
StaxBuilder, PortComponentHandlerType, ParamValueType not found
Hi Sergey: I imported every cxf-* subproject into eclipse(m2eclipse) this time, and there is a problem in my eclipse, I don't see these 3 class: cxf-rt-frontend-jaxws import org.apache.cxf.jaxws.javaee.ParamValueType; import org.apache.cxf.jaxws.javaee.PortComponentHandlerType; cxf-rt-databinding-aegis import org.apache.cxf.aegis.util.jdom.StaxBuilder; And I checked the 'generated' folder, and they are not there. When I google them, they should be in their src, am I missing something? Thank you. Regards: Shenglin Qiu
RE: StaxBuilder, PortComponentHandlerType, ParamValueType not found
Hi Jiang: Thank you! I then find it under src/main/generated, instead of target/generated. Regards: Shenglin Qiu > Date: Fri, 22 Apr 2011 12:35:43 +0800 > From: willem.ji...@gmail.com > To: dev@cxf.apache.org > Subject: Re: StaxBuilder, PortComponentHandlerType, ParamValueType not found > > Hi, > > Did you have chance the run mvn clean install -Pfastinstall before > import the cxf projects into eclipse. > > You will find these class in the generated folder :) > > > On 4/21/11 11:17 PM, Shenglin Qiu wrote: > > > > Hi Sergey: > > > > I imported every cxf-* subproject into eclipse(m2eclipse) this time, and > > there is a problem in my eclipse, I don't see these 3 class: > > > > cxf-rt-frontend-jaxws > > import org.apache.cxf.jaxws.javaee.ParamValueType; > > import org.apache.cxf.jaxws.javaee.PortComponentHandlerType; > > > > cxf-rt-databinding-aegis > > import org.apache.cxf.aegis.util.jdom.StaxBuilder; > > > > And I checked the 'generated' folder, and they are not there. When I google > > them, they should be in their src, am I missing something? > > > > Thank you. > > > > Regards: > > Shenglin Qiu > > > > > -- > Willem > -- > FuseSource > Web: http://www.fusesource.com > Blog:http://willemjiang.blogspot.com (English) > http://jnn.javaeye.com (Chinese) > Twitter: willemjiang > > Connect at CamelOne May 24-26 > The Open Source Integration Conference > http://camelone.com
RE: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources
Hi Sergey:
Happy Holiday!
I can't believe it's not a US holiday and at least people in MA have to work:(
I will ping you tomorrow.
Thank you very much!
Regards:
Shenglin Qiu
> 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 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
> >
RE: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources
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.
cxf
service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi
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:
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:
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 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 expose
RE: ServerLifeCycleListener and JMXServer
Yes, Sergey.
I should have finished listing MBeans correctly and fully first, and then look
forward for the next.
I will make my code cleaner, my code is synced at
https://github.com/dabaipang/demoserver
Regards:
Shenglin Qiu
> Date: Thu, 5 May 2011 10:43:59 +0100
> Subject: Re: ServerLifeCycleListener and JMXServer
> From: sberyoz...@gmail.com
> To: dabaip...@hotmail.com
> CC: dev@cxf.apache.org
>
> Hi Shenglin
>
> Thanks for this update. I'd like to clarify why I suggested adding
> ServerLifeCycleManager listener.
> The only reason is for JMXServer to be able to keep an internal
> uptodate list of existing CXF endpoints which are currently being
> managed.
>
> Please check the comments I made in the other (main) thread about it.
> Lets focus right now on only GETing the representations of:
> 1. All CXF MBeans representing all the CXF endpoints
> 2. CXF service-specific MBeans
>
> I believe you've nearly implemented 1. In order to implement 2, we
> need to know the list of existing CXF services (not MBeans) and
> JMXServer needs to return this list (getListOfManagedServices or
> similar). Next, JMXServer has to be able to return service-scoped
> MBeans (see 2.), it should have a resource method accepting the
> service expanded qname ({http://bar}service or similar) and return a
> collection of MBeans relevant to this particular service only
> (Service, its Endpoints as well as the bus - the bus is not
> necessarily endpoint specific - but is relevant).
>
> So whenever your ServerLifeCycleManager listener gets an event it
> updates the (concurrent/thread-safe) list accordingly.
>
> The question is how to get this list (task 2.) initialized with the
> list of service qnames which have already been created, by the time
> JMXServer is being created itself. Looks like you need to get a
> ServerRegistry extension from the bus and get a list of existing
> Servers (and Services) from it.
>
> Please see more comments inline
>
> On Thu, May 5, 2011 at 4:04 AM, Shenglin Qiu wrote:
> > Hi Sergey:
> >
> > As you mentioned last time, I am trying to have this
> > ServerLifeCycleManager.class into
> >
> > private ServerLifeCycleManager lifeCycleManager;
> >
> > public void setInstrumentationManager(InstrumentationManagerImpl
> > instrumentationManager) {
> > this.instrumentationManager = instrumentationManager;
> > lifeCycleManager =
> > instrumentationManager.getBus().getExtension(ServerLifeCycleManager.class);
> > lifeCycleManager.registerListener(new ServerLifeCycleListener() {
> > public void startServer(Server server) {
> > String address =
> > server.getEndpoint().getEndpointInfo().getAddress();
> > }
> > public void stopServer(Server server) {
> > String address =
> > server.getEndpoint().getEndpointInfo().getAddress();
> > }
> > });
> > }
> >
> > @GET
> > @POST
> > @Path("start")
> > public CxfMBeanCollection start(){
> > lifeCycleManager.startServer(server);
> >
> > return ?;
> > }
> >
> > @GET
> > @POST
> > @Path("stop")
> > public CxfMBeanCollection stop(){
> > lifeCycleManager.startServer(server);
> >
> > return ?;
> > }
> >
> >
> > I am stuck at getting a server instance in start() and stop(); Here is my
> > applicationContext.xml, I think if applicationContext is loaded, then all
> > Jax-Ws and Jax-Rs are started by default, then up in start() function will
> > have duplicated starting issue. I am thinking, should I use non-spring
> > approach, and create JAXRSServerFactoryBean -> create endpoint -> start
> > server in plain java code at first?
>
> JMXServer should not deal with starting/stopping CXF endpoints - at
> least not at the initial stage,
> at the moment its main 'responsibility' is to show all relevant MBeans
> and also access properties of individual MBeans, and may be modify
> some of the properties, when possible.
>
>
> > Either way, I will spend some time more reading jax-rs-frontend-* module.
> >
> >
> > > address="/PersonService">
> >
> > > />
> > > class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
> >
> >
> >
> >
> >
Expose MBeans in CXF
Hi Sergey:
I have tested my current code and these are working fine:
http://localhost:8080/demoserver/jaxserver/jmxserver/port/%22UserServiceImpl%22
http://localhost:8080/demoserver/jaxserver/jmxserver/type/Bus.Service.Endpoint
I will work on this " sign which is %22 in the URL and try to remove it.
This is not working
http://localhost:8080/demoserver/jaxserver/jmxserver/service/{http://web.management.gsoc.cxf.apache.org/}DJMXServer
which is :
http://localhost:8080/demoserver/jaxserver/jmxserver/service/%7Bhttp://web.management.gsoc.cxf.apache.org/%7DJMXServer
It simply return 404 error. I guess it's the restriction from CXF Rest inbound,
then I tried:
http://localhost:8080/demoserver/jaxserver/jmxserver/service/service?{http://web.management.gsoc.cxf.apache.org/}DJMXServer
http://localhost:8080/demoserver/jaxserver/jmxserver/service/service={http://web.management.gsoc.cxf.apache.org/}DJMXServer
They didn't work neither. Because when = in request, it's still 404, and when ?
in request, I only get 'service' as the @PathParam in the input, the rest of
the part is lost.
So is there any way I can pass string like 'http://**' as a part of request
in cxf?
BTW, I will have the NDA ready this week.
Thank you.
Regards
Shenglin Qiu
RE: Expose MBeans in CXF
bean by type
http://localhost:8080/demoserver/jaxserver/jmxserver/port/%22UserServiceImpl%22
=> get Mbean by service, %22 is an issue which I
can't get rid of it, still working on it.
http://localhost:8080/demoserver/jaxserver/jmxserver/service/impl.service.ws.gsoc.cxf.apache.org
=> get Mbean by part of service such as
{http://impl.service.ws.gsoc.cxf.apache.org/}CustomerServiceImpl ->
impl.service.ws.gsoc.cxf.apache.org
Thank you.
Regards:
Shenglin Qiu
> Date: Thu, 12 May 2011 14:23:36 +0100
> Subject: Re: Expose MBeans in CXF
> From: sberyoz...@gmail.com
> To: dev@cxf.apache.org
>
> Hi Shenglin
>
> Thanks for the update. Can you please copy the summary from the
> previous email, where one possible approach going forward was
> discussed and describe what you've done so far in context of that
> summary ?
> Looks like you are progressing well, however I'm not exactly sure what
> exactly you are trying to do.
>
> More comments inline
>
> On Thu, May 12, 2011 at 1:53 PM, Shenglin Qiu wrote:
> >
> > Hi Sergey:
> >
> > I have tested my current code and these are working fine:
> > http://localhost:8080/demoserver/jaxserver/jmxserver/port/%22UserServiceImpl%22
> > http://localhost:8080/demoserver/jaxserver/jmxserver/type/Bus.Service.Endpoint
> >
> > I will work on this " sign which is %22 in the URL and try to remove it.
>
> Please update us first on what you've done so far, why you are passing
> "UserServiceImpl" as the final segment is unclear at the moment
>
> >
> > This is not working
> > http://localhost:8080/demoserver/jaxserver/jmxserver/service/{http://web.management.gsoc.cxf.apache.org/}DJMXServer
> > which is :
> > http://localhost:8080/demoserver/jaxserver/jmxserver/service/%7Bhttp://web.management.gsoc.cxf.apache.org/%7DJMXServer
> >
> > It simply return 404 error. I guess it's the restriction from CXF Rest
> > inbound,
>
> Well, I believe CXF 2.4.0 and CXF 2.3.5 have no problems at all with
> handling all sort of encoded URIs, earlier versions had some issues
> when matrix params were used or some specific characters were encoded.
> So try the latest versions.
> However, what I'd really encourage you to do is to make sure you
> understand why the above is not working, by debugging the JAX-RS
> runtime code and see what might be going wrong
>
> > then I tried:
> > http://localhost:8080/demoserver/jaxserver/jmxserver/service/service?{http://web.management.gsoc.cxf.apache.org/}DJMXServer
> > http://localhost:8080/demoserver/jaxserver/jmxserver/service/service={http://web.management.gsoc.cxf.apache.org/}DJMXServer
> > They didn't work neither. Because when = in request, it's still 404, and
> > when ? in request, I only get 'service' as the @PathParam in the input, the
> > rest of the part is lost.
>
> '?' identifies the start of the query component, so that is not
> captured, and please check why '=' is not working. Perhaps something
> to do with @Path values ?
>
> >
> > So is there any way I can pass string like 'http://**' as a part of
> > request in cxf?
> >
> Yes, pass it as a query parameter value, ex ?component=http://bar or
> as the value of the path segment
>
> > BTW, I will have the NDA ready this week.
> >
> it's ICLA
>
> http://www.apache.org/licenses/icla.txt
>
> Please try to update the dev list at least twice per week and login to
> #cxf if you have questions. We should be finalizing by now the
> retrieval of MBean representations and start planning what to do next
>
> Thanks, Sergey
>
> > Thank you.
> >
> > Regards
> > Shenglin Qiu
> >
> >
>
>
>
> --
> Sergey Beryozkin
>
> Application Integration Division of Talend
> http://sberyozkin.blogspot.com
RE: Expose MBeans in CXF
Hi Sergey:
Here are what I had and although the output maybe simple, I checked outputs and
they look alright, need your opinions:)
1.
Request URL: this is from searching part of endpoint
service="{http://impl.service.ws.gsoc.cxf.apache.org/}CustomerServiceImpl";
http://localhost:8080/demoserver/jaxserver/jmxserver/service/impl.service.ws.gsoc.cxf.apache.org
Response:
org.apache.cxf:bus.id=cxf568097598,port="CustomerServiceImpl",service="{http://impl.service.ws.gsoc.cxf.apache.org/}CustomerServiceImpl",type=Bus.Service.Endpoint
org.apache.cxf
"{http://impl.service.ws.gsoc.cxf.apache.org/}CustomerServiceImpl";
org.apache.cxf:bus.id=cxf568097598,port="JaxRsJMXServiceImpl",service="{http://impl.service.ws.gsoc.cxf.apache.org/}JaxRsJMXServiceImpl",type=Bus.Service.Endpoint
org.apache.cxf
"{http://impl.service.ws.gsoc.cxf.apache.org/}JaxRsJMXServiceImpl";
org.apache.cxf:bus.id=cxf568097598,port="UserServiceImpl",service="{http://impl.service.ws.gsoc.cxf.apache.org/}UserServiceImpl",type=Bus.Service.Endpoint
org.apache.cxf
"{http://impl.service.ws.gsoc.cxf.apache.org/}UserServiceImpl";
2.
Request: search port="UserServiceImpl"
http://localhost:8080/demoserver/jaxserver/jmxserver/port/"UserServiceImpl";
Response:
org.apache.cxf:bus.id=cxf568097598,port="UserServiceImpl",service="{http://impl.service.ws.gsoc.cxf.apache.org/}UserServiceImpl",type=Bus.Service.Endpoint
org.apache.cxf
"UserServiceImpl"
3.
Request: search by ObjectName("***")
http://localhost:8080/demoserver/jaxrs3/jmx/component/org.apache.cxf:type=Bus.Service.Endpoint,*
Response:
org.apache.cxf:bus.id=cxf568097598,port="JaxRsJMXServiceImpl",service="{http://impl.service.ws.gsoc.cxf.apache.org/}JaxRsJMXServiceImpl",type=Bus.Service.Endpoint
org.apache.cxf
org.apache.cxf:bus.id=cxf568097598,port="JMXServer",service="{http://web.management.gsoc.cxf.apache.org/}JMXServer",type=Bus.Service.Endpoint
org.apache.cxf
org.apache.cxf:bus.id=cxf568097598,port="CustomerServiceImpl",service="{http://impl.service.ws.gsoc.cxf.apache.org/}CustomerServiceImpl",type=Bus.Service.Endpoint
org.apache.cxf
org.apache.cxf:bus.id=cxf568097598,port="UserServiceImpl",service="{http://impl.service.ws.gsoc.cxf.apache.org/}UserServiceImpl",type=Bus.Service.Endpoint
org.apache.cxf
My current inbound config ():
{http://impl.service.ws.gsoc.cxf.apache.org/}CustomerServiceImpl
{http://web.management.gsoc.cxf.apache.org/}JMXServer
{http://impl.service.ws.gsoc.cxf.apache.org/}UserServiceImpl
{http://impl.service.ws.gsoc.cxf.apache.org/}JaxRsJMXServiceImpl
I am planning to use this weekend, clean this config and code up, and make Rest
request url shorter as you mentioned. I need your suggestions and ideas. and I
think I am ready for a big surgery on the demoserver.
Code is still in https://dabaip...@github.com/dabaipang/demoserver.git
Also, I will go to supermarket and find a scanner for the NDS
Thank you very much!
Regards:
Shenglin Qiu
> Date: Fri, 13 May 2011 11:11:51 +0100
> Subject: Re: Expose MBeans in CXF
> From: sberyoz...@gmail.com
> To: dev@cxf.apache.org
>
> Hi
>
> On Fri, May 13, 2011 at 1:19 AM, Shenglin Qiu wrote:
> >
> > Hi Sergey:
> >
> > Here is the todo list which you have assigned:
> >
> > 1. Have one JAX-WS and JAX-RS endpoints
> > 2. Have your JMXServer as a separate endpoint
> > 3. Injecting a bus reference and registering a listener
> >
> > Your Tips:
> > 1.
> > In
> > the method where bus is injected, get ServerLifeCycleManager.class
> > extension from the bus and register your own ServerLifeCy
RE: Expose MBeans in CXF
Hi Sergey:
Thank you very much you replied me on weekends!
I put the comments bellow:
1.
http://localhost:8080/demoserver/jaxserver/jmxserver/service/impl.service.ws.gsoc.cxf.apache.org
> > What is this query supposed to mean ? Get all Mbeans representing
> > endpoints whose implementations are in
> > "impl.service.ws.gsoc.cxf.apache.org" package ?
If I didn't explicitly define endpointName in service class, the endpointName
will be like {http://impl.service.ws.gsoc.cxf.apache.org/}UserServiceImpl, and
http://localhost:8080/demoserver/jaxserver/jmxserver/service/impl.service.ws.gsoc.cxf.apache.org
can search whether there is a match like this String
'impl.service.ws.gsoc.cxf.apache.org' in the endpointName, I know it turns out
useless if I didn't do the following right at first:
> > We need to be able to get the list of MBean *related to* a particular
> > service name, such as
> > {http://impl.service.ws.gsoc.cxf.apache.org/}UserServiceImpl.
> >
Actually this is where I get stucked, I tried to put request like
http://localhost:8080/demoserver/jaxserver/jmxserver/service/{http://impl.service.ws.gsoc.cxf.apache.org/}UserServiceImpl
But I get 400 error: request not found and here are part of your comments,
> >>> Can you please describe what you've done ?
> >>>
> >>> > I am actually stopped at this GET request:
> >>> > I tried:
> >>> >
>
>>> >
http://localhost:8080/demoserver/jaxserver/jmxserver/service/{http://impl.service.ws.gsoc.cxf.apache.org/}CustomerServiceImpl
> >>> > And obviously it doesn't work because of the slash in url is not
> >>> > accepted. (I still didn't find a reasonable answer from searching
> >>> > google,
> >>> > shocking)
> >>> >
> >>> Shenglin, you are obviously very well prepared technically but you
> >>> need to change the approach and do it asap. Why do you expect Google
> >>> to tell you why the above URI does not work ?
> >>>
> >>> That URI seems too long anyway
> >>>
> >>>
> >>> http://localhost:8080/demoserver/jmx?service={http://impl.service.ws.gsoc.cxf.apache.org/}CustomerServiceImpl
> >>>
> >>> Is the max really and in this particular case I'm presuming this query
> >>> is about getting the list of MBeans reps for a particular managed
> >>> service. Perhaps in the future we can allocate dynamic subresources
> >>> instead for handling endpoint specific MBeans to make URIs shorter for
> >>> this particular case.
> >>>
I am still working on it, I think this is the core part of this mission, and
from your replies, I can see you want this query to be done correctly as it is
in the red line.
2.
> >> "{http://impl.service.ws.gsoc.cxf.apache.org/}UserServiceImpl";
> >>
> >>
> >>
> >>
> >>
> >
> > Please remove "Cxf" prefixes and we also don't need to expose
> > JaxRsJMXServiceImpl
Yes, I am removing/modifying it very fast.
3.
> >>
> >> >> class="org.apache.cxf.gsoc.management.web.JMXServer">
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> {http://impl.service.ws.gsoc.cxf.apache.org/}CustomerServiceImpl
> >>
> >> {http://web.management.gsoc.cxf.apache.org/}JMXServer
> >>
> >> {http://impl.service.ws.gsoc.cxf.apache.org/}UserServiceImpl
> >>
> >> {http://impl.service.ws.gsoc.cxf.apache.org/}JaxRsJMXServiceImpl
> >>
> >>
> >>
> >
> > You said you've managed to avoid injecting references to individual
> > managed endpoints, I thought we agree that injecting
> > InstrumentationManager would be sufficient.
Yes, actually this part is not necessary:
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
I will remove it very fast, the reason I put here is you have mentioned do
things like
>
> ? ?
> ? ? ? ?
> ? ? ? ? ? ?{http://users.com/rs}UserService
> ? ? ? ? ? ?{http://user
RE: Expose MBeans in CXF
Hi Sergey:
I was pulling name list out and when I type 'se', the first one now is
secret...@apache.org, my mistake.
I pulled your comment out and made @Todo replies:
>
> Well, /soapdemo is confusing.
> Have the context named as "/services" or "/application" and set the
> address of SOAP endpoint as "/soap/greeter" or simply "/greeter" as
> you do now.
>
Yes, it's done. I will use project name services
> I think you meant to say: > http://localhost:8080/soapdemo/jmx
> which is the address of your JMX server endpoint which should be changed to
> say"http://localhost:8080/services/jmx";.
Yes, I changed the project name as well as context path as you mentioned:
Project name: services
Context path: services
> http://localhost:8080/soapdemo/jmx/service/{http://server.gsoc.apache.org/}*
@Todo: I will get this done real quick. to make it like
http://localhost:8080/services/jmx/service/{http://server.gsoc.apache.org/}*
> OK. Please remove MBeanCollection wrapper, you have another wrapper, MBeans.
> No need to have quotes around endpointName's value.How about having MBean
> representation structured like this:
>
> org.apache.cxf
>
> org.apache.cxf:bus.id=cxf5663550,
> port="CustomerServiceImpl",
> service="{http://server.gsoc.apache.org/}CustomerServiceImpl";,
> type=Bus.Service.Endpoint
>
>
>
@Todo: I will remove , and put in.
> http://localhost:8080/soapdemo/jmx/mbean/1";>
@Todo: I will add it real quick.
> So please update MBean class to have "href" attribute (with@XmlAttribute).
> Have a '@Context UriInfo uriinfo' field in JMXServerclass.
> When you create a response for /list or /service/*, etc,
> useUriInfo to get to the *base* UriBuilder which will represent a URIlike
> "http://localhost:8080/soapdemo/jmx";.
> Next add "mbean" and then a number like 1/2/etc which identifies a particular
> MBean,
> may be ashort objectname instead of the compete canonical name, etc,
> so and have UriBuilder to return
> you'http://localhost:8080/soapdemo/jmx/mbean/1', etc:
> String href = builder.path("mbean").path(someUniqueKey).build().toString()
@Todo: I will have this unique key implemented in href="", and:
@Context
UriInfo uriinfo
> Your JMXServer should have a subresource locator, with @Path("mbean") and
> without HttpMethod.
> This locator will return something like MBeanResource and that class,at this
> stage,
> will have *only*a single @GET resource method with @Path("{key}") and
> which will return the above MBean representaion only, without MBeans wrapper:
> GET http://localhost:8080/soapdemo/jmx/mbean/1
@Todo: subresource locator, with @Path("mbean") and without HttpMethod:
I will have this done.
Thank you very much.
Regards:
Shenglin Qiu
> Date: Wed, 18 May 2011 11:38:24 +0100
> Subject: Re: Expose MBeans in CXF
> From: sberyoz...@gmail.com
> To: dev@cxf.apache.org
>
> Hi Shenglin
>
> Well done, you are progressing well.
>
> Note that you don't have to start formatting the updates to the dev
> list, it's just
> the work as usual, keep it simple please :-). And don't CC to the secretary
> :-)
>
> Some comments below.
>
> > I am fully upgrade it to 2.4.0, I have some testing phase exceptions
> > ocurring even I don't have a test case in maven test src folder. I will
> > figure this out later after this doc.
> >
> If you are seeing some unrelated test failures when building the trunk
> then add '-Pfastinstall'
>
> > The RAR src is attached, hope this 'soap' won't confuse you, it actually has
> > 1 soap inbound and 2 restful inbounds. I am always stuck at the naming,
> > previous demoserver has been down when I was upgrading, that's another
> > story, and I will fix it.
> >
>
> Well, /soapdemo is confusing.
> Have the context named as "/services" or "/application" and set the
> address of SOAP endpoint as "/soap/greeter" or simply "/greeter" as
> you do now.
>
>
> >
> > Here are the 3 enabled inbound service, including 1 soap webservice and 2
> > Restful service:(They are up and running)
> >
> > http://localhost:8080/soapdemo/greeter?wsdl
> >
> > http://localhost:8080/soapdemo/customerservice/customers
> >
> > http://localhost:8080/soapdemo/customerservice/customer/firstname/Lois
> >
> > http://localhost:8080/soapdemo/customerservice/customer/id/1
> >
> > http://localhost:8080/soapdemo/userse
RE: Expose MBeans in CXF
Hi Sergey:
I am now at this step from your comment:
> Now, there's one thing which is missing from the above representation
> and it is a link to a resource which will deal with a particular MBean
> (possible updates of properties, handling the notifications). We need
> to put it all into a more practical surface so it should be something
> like
>
>
> http://localhost:8080/soapdemo/jmx/mbean/1";>
> org.apache.cxf
>
org.apache.cxf:bus.id=cxf5663550,port="CustomerServiceImpl",service="{http://server.gsoc.apache.org/}CustomerServiceImpl",type=Bus.Service.Endpoint
>
> http://localhost:8080/soapdemo/jmx/mbean/2";>
> org.apache.cxf
>
org.apache.cxf:bus.id=cxf5663551,port="UserServiceImpl",service="{http://server.gsoc.apache.org/}UserServiceImpl",type=Bus.Service.Endpoint
>
>
>
> where http://localhost:8080/soapdemo/jmx/mbean/1,
> http://localhost:8080/soapdemo/jmx/mbean/2, etc, uniquely identify
> those individual MBeans only.
>
> So please update MBean class to have "href" attribute (with
> @XmlAttribute). Have a '@Context UriInfo uriinfo' field in JMXServer
> class. When you create a response for /list or /service/*, etc, use
> UriInfo to get to the *base* UriBuilder which will represent a URI
> like "http://localhost:8080/soapdemo/jmx";. Next add "mbean" and then a
> number like 1/2/etc which identifies a particular MBean, may be a
> short objectname instead of the compete canonical name, etc, so and
> have UriBuilder to return you
> 'http://localhost:8080/soapdemo/jmx/mbean/1', etc:
>
> String href = builder.path("mbean").path(someUniqueKey).build().toString()
Here is my progress, I use UriBuilder uriBuilder =
uriInfo.getAbsolutePathBuilder().path(this.getClass(), "list"); and
String uniqueKey = Integer.toString(index++);
String href = uriBuilder.path(uniqueKey).build().toString();
in each MBean.
(Actually, the result is something I never studied before. This is a very
interesting topic. I will spend more time on it.)
My current response on this url: http://localhost:8080/services/jmx/
http://localhost:8080/services/jmx/list/0";>
cxf33425430
"UserServiceImpl"
"{http://server.gsoc.apache.org/}UserServiceImpl";
Bus.Service.Endpoint
org.apache.cxf:bus.id=cxf33425430,port="UserServiceImpl",service="{http://server.gsoc.apache.org/}UserServiceImpl",type=Bus.Service.Endpoint
org.apache.cxf
http://localhost:8080/services/jmx/list/0/1/2/3/4/5";>
MBeanServerDelegate
JMImplementation:type=MBeanServerDelegate
JMImplementation
http://localhost:8080/services/jmx/list/0/1/2/3";>
cxf33425430
Bus
org.apache.cxf:bus.id=cxf33425430,type=Bus
org.apache.cxf
http://localhost:8080/services/jmx/list/0/1/2/3/4";>
cxf33425430
"SoapPort"
"{http://org.apache.gsoc.server/Greeter_Soap}SOAPService";
Bus.Service.Endpoint
org.apache.cxf:bus.id=cxf33425430,port="SoapPort",service="{http://org.apache.gsoc.server/Greeter_Soap}SOAPService",type=Bus.Service.Endpoint
org.apache.cxf
http://localhost:8080/services/jmx/list/0/1";>
cxf33425430
"JMXServer"
"{http://server.gsoc.apache.org/}JMXServer";
Bus.Service.Endpoint
org.apache.cxf:bus.id=cxf33425430,port="JMXServer",service="{http://server.gsoc.apache.org/}JMXServer",type=Bus.Service.Endpoint
org.apache.cxf
http://localhost:8080/services/jmx/list/0/1/2";>
cxf33425430
"CustomerServiceImpl"
"{http://server.gsoc.apache.org/}CustomerServiceImpl";
Bus.Service.Endpoint
org.apache.cxf:bus.id=cxf33425430,port="CustomerServiceImpl",service="{http://server.gsoc.apache.org/}CustomerServiceImpl",type=Bus.Service.Endpoint
org.apache.cxf
Of course, as you required, I format the output.
Regards:
Shenglin Qiu
> Date: Wed, 18 May 2011 11:38:24 +0100
> Subject: Re: Expose MBeans in CXF
> From: sberyoz...@gmail.com
> To: dev@cxf.apache.org
>
> Hi Shenglin
>
> Well done, you are progressing well.
>
> Note that you don't have to start formatting the updates to the dev
> list, it's just
> the work as usual, keep it simple please :-). And don't CC to the secretary
> :-)
>
> Some comments below.
>
> > I am fully upgrade it to 2.4.0, I have some testing phase exceptions
> > ocurring e
RE: Expose MBeans in CXF
Hi Sergey
I have now having this response as you commented:
http://localhost:8080/services/jmx/list/mbean/0/mbean/1/mbean/2/mbean/3/mbean/4";>
cxf29162475
"SoapPort"
"{http://org.apache.gsoc.server/Greeter_Soap}SOAPService";
Bus.Service.Endpoint
org.apache.cxf:bus.id=cxf29162475,port="SoapPort",service="{http://org.apache.gsoc.server/Greeter_Soap}SOAPService",type=Bus.Service.Endpoint
org.apache.cxf
http://localhost:8080/services/jmx/list/mbean/0/mbean/1/mbean/2/mbean/3";>
cxf29162475
"CustomerServiceImpl"
"{http://server.gsoc.apache.org/}CustomerServiceImpl";
Bus.Service.Endpoint
org.apache.cxf:bus.id=cxf29162475,port="CustomerServiceImpl",service="{http://server.gsoc.apache.org/}CustomerServiceImpl",type=Bus.Service.Endpoint
org.apache.cxf
http://localhost:8080/services/jmx/list/mbean/0/mbean/1";>
cxf29162475
"UserServiceImpl"
"{http://server.gsoc.apache.org/}UserServiceImpl";
Bus.Service.Endpoint
org.apache.cxf:bus.id=cxf29162475,port="UserServiceImpl",service="{http://server.gsoc.apache.org/}UserServiceImpl",type=Bus.Service.Endpoint
org.apache.cxf
Because there are 2 unrelated MBean filtered out,
http://localhost:8080/services/jmx/list/mbean/0 -> CXF BUS
http://localhost:8080/services/jmx/list/mbean/0/mbean/1/mbean/2 -> My own jaxrs
mbean server as you mentioned it must be filtered
and also , this is filtered out as you mentioned
> >
>
> > http://localhost:8080/services/jmx/list/0/1/2/3/4/5";>
> >
> > MBeanServerDelegate
> >
> >
> > JMImplementation:type=MBeanServerDelegate
> > JMImplementation
> >
therefore, now href is somehow not continuous as followed, is it ok just for a
unique identifier for the MBean we want?
http://localhost:8080/services/jmx/list/mbean/0/mbean/1 ->
restful UserService
http://localhost:8080/services/jmx/list/mbean/0/mbean/1/mbean/2/mbean/3 ->
restful CustomerService
http://localhost:8080/services/jmx/list/mbean/0/mbean/1/mbean/2/mbean/3/mbean/4
-> soap Greeter
Thank you.
Regards:
Shenglin Qiu
> Date: Thu, 19 May 2011 10:20:19 +0100
> Subject: Re: Expose MBeans in CXF
> From: sberyoz...@gmail.com
> To: dabaip...@hotmail.com
> CC: dev@cxf.apache.org
>
> HI Shenglin
>
> >>
> >> String href = builder.path("mbean").path(someUniqueKey).build().toString()
> >
> >
> > Here is my progress, I use UriBuilder uriBuilder =
> > uriInfo.getAbsolutePathBuilder().path(this.getClass(), "list"); and
> > String uniqueKey = Integer.toString(index++);
> > String href = uriBuilder.path(uniqueKey).build().toString();
> > in each MBean.
> >
> >
> > (Actually, the result is something I never studied before. This is a very
> > interesting topic. I will spend more time on it.)
>
> Indeed, it's interesting.
>
> You actually need to use uriInfo.getBaseUriBuilder() instead and add
> "mbean" segment followed by some
> unikey key. Using uriInfo.getBaseUriBuilder() will make sure that
> irrespectively of whether you have a /list or /service/* or /type/*
> query, you will alway get the same result for MBean href.
>
> More comments below.
>
> >
> > My current response on this url: http://localhost:8080/services/jmx/
>
> >
>
> >http://localhost:8080/services/jmx/list/0/1/2/3/4/5";>
> >
> > MBeanServerDelegate
> >
> >
> > JMImplementation:type=MBeanServerDelegate
> > JMImplementation
> >
>
>
> MBeans which are not in the org.apace.cxf domain have to be dropped.
> We can have the name of the domain injected as a property in the
> future. At the moment have a 'final String DOMAIN_NAME' constant and
> use it to filter out non-CXF MBeans
>
> The other note is that it should always be
> "http://localhost:8080/services/jmx/mbean/{someuniquekey}";
> with the key being 1, 2, or something more descriptive which can
> uniquely identify a given MBean. You probably need to keep a
> ConcurrentHashMap, where keys are 1, 2, and values are canonical
> names, something like that, so that when you get a request like
> "http://localhost:8080/services/jmx/mbean/1"; you can retrieve the
> corresponding Object name and do something with it
>
> >http://localhost:8080/services/jmx/list/0/1";>
> >
> &g
RE: Expose MBeans in CXF
Yes Sergey, will have these following pattern:
http://localhost:8080/services/jmx/mbean/0 -> CXF Bus
http://localhost:8080/services/jmx/mbean/01 -> UserService
http://localhost:8080/services/jmx/mbean/0123 -> CustomerService
http://localhost:8080/services/jmx/mbean/01234 -> GreeterService (Soap)
http://localhost:8080/services/jmx/mbean/012 -> JMXServer will be hidden to
user.
Regards:
Shenglin Qiu
> Date: Thu, 19 May 2011 14:19:13 +0100
> Subject: Re: Expose MBeans in CXF
> From: sberyoz...@gmail.com
> To: dabaip...@hotmail.com
> CC: dev@cxf.apache.org
>
> Hi Shenglin
>
> Please don't copy all the response collection, copy only relevant fragments.
>
> >
> > Because there are 2 unrelated MBean filtered out,
> >
> > http://localhost:8080/services/jmx/list/mbean/0 -> CXF BUS
>
> CXF Bus is definitely relevant, as it is in the org.apache.cxf domain.
> Please include it whenever suitable, ex, when listing all MBeans, when
> a /type/* query matches it, etc
>
>
> > therefore, now href is somehow not continuous as followed, is it ok just
> > for a unique identifier for the MBean we want?
> >
> > http://localhost:8080/services/jmx/list/mbean/0/mbean/1
> > -> restful UserService
> > http://localhost:8080/services/jmx/list/mbean/0/mbean/1/mbean/2/mbean/3
> > -> restful CustomerService
> > http://localhost:8080/services/jmx/list/mbean/0/mbean/1/mbean/2/mbean/3/mbean/4
> > -> soap Greeter
>
> All MBeans, irrespectively of whether you used /list or /service/*,
> etc query, should have this format:
>
> http://localhost:8080/services/jmx/mbean/1
> or
> http://localhost:8080/services/jmx/mbean/23
> or
> http://localhost:8080/services/jmx/mbean/99
> or
> http://localhost:8080/services/jmx/mbean/bus.service.id.1
>
> Note, no 'list' is there. And the key is a simple value like 1 or 23, etc.
>
> Do you see what I mean ?
>
> Cheers, Sergey
>
> >
> > Thank you.
> >
> >
> > Regards:
> > Shenglin Qiu
> >
> >
> >
> >> Date: Thu, 19 May 2011 10:20:19 +0100
> >> Subject: Re: Expose MBeans in CXF
> >> From: sberyoz...@gmail.com
> >> To: dabaip...@hotmail.com
> >> CC: dev@cxf.apache.org
> >>
> >> HI Shenglin
> >>
> >> >>
> >> >> String href =
> >> >> builder.path("mbean").path(someUniqueKey).build().toString()
> >> >
> >> >
> >> > Here is my progress, I use UriBuilder uriBuilder =
> >> > uriInfo.getAbsolutePathBuilder().path(this.getClass(), "list"); and
> >> > String uniqueKey = Integer.toString(index++);
> >> > String href =
> >> > uriBuilder.path(uniqueKey).build().toString();
> >> > in each MBean.
> >> >
> >> >
> >> > (Actually, the result is something I never studied before. This is a
> >> > very
> >> > interesting topic. I will spend more time on it.)
> >>
> >> Indeed, it's interesting.
> >>
> >> You actually need to use uriInfo.getBaseUriBuilder() instead and add
> >> "mbean" segment followed by some
> >> unikey key. Using uriInfo.getBaseUriBuilder() will make sure that
> >> irrespectively of whether you have a /list or /service/* or /type/*
> >> query, you will alway get the same result for MBean href.
> >>
> >> More comments below.
> >>
> >> >
> >> > My current response on this url: http://localhost:8080/services/jmx/
> >>
> >> >
> >>
> >> >http://localhost:8080/services/jmx/list/0/1/2/3/4/5";>
> >> >
> >> > MBeanServerDelegate
> >> >
> >> >
> >> > JMImplementation:type=MBeanServerDelegate
> >> > JMImplementation
> >> >
> >>
> >>
> >> MBeans which are not in the org.apace.cxf domain have to be dropped.
> >> We can have the name of the domain injected as a property in the
> >> future. At the moment have a 'final String DOMAIN_NAME' constant and
> >> use it to filter out non-CXF MBeans
> >>
> >> The other note is that it should always be
> >> "http://localhost:8080/services/jmx/mbean/{someuniquekey}";
> >> with the key being 1, 2, or something more descriptive which can
> >> uniquely identify a given MBean. You probably need to keep a
> >> ConcurrentHashMap, w
RE: Expose MBeans in CXF
Yes, Sergey, Should I manually give/define every mbean an indexer which is accumulated as you mentioned? > > http://localhost:8080/services/jmx/mbean/0 > > http://localhost:8080/services/jmx/mbean/1 > > http://localhost:8080/services/jmx/mbean/2 ... > > http://localhost:8080/services/jmx/mbean/*** Thank you. Regards: Shenglin Qiu > Date: Thu, 19 May 2011 15:03:03 +0100 > Subject: Re: Expose MBeans in CXF > From: sberyoz...@gmail.com > To: dev@cxf.apache.org > > HI Shenglin > > On Thu, May 19, 2011 at 2:54 PM, Shenglin Qiu wrote: > > > > Yes Sergey, will have these following pattern: > > > > http://localhost:8080/services/jmx/mbean/0 -> CXF Bus > > > > http://localhost:8080/services/jmx/mbean/01 -> UserService > > > > http://localhost:8080/services/jmx/mbean/0123 -> CustomerService > > > > http://localhost:8080/services/jmx/mbean/01234 -> GreeterService (Soap) > > > > http://localhost:8080/services/jmx/mbean/012 -> JMXServer will be hidden > > to user. > > > > That looks better, but do you think it would make sense to avoid the > concatenation ? > We can get hundreds of CXF MBeans in the production environment, so > IMHO it would be simpler > to have /mbean/199 identifying a particular MBean, > > Cheers, Sergey > > > > > Regards: > > > > Shenglin Qiu > > > > > >
RE: Expose MBeans in CXF
Hi Sergey:
> >
> > However, I have to make http://localhost:8080/services/jmx/ at every time I
> > am trying to do anything further, because I need to use this following
> > function to load up all mbeans along with their /mbean/** unique
> > identifiers, and I think this may not be what you want. Please correct me on
> > this.
> >
> Are you saying that you have to use UriInfo and UriBuilder for
> creating hrefs whenever you need to
> build an MBean representation ?
>
After everytime server bounces, I need to at first use this url request:
http://localhost:8080/services/jmx/, the good thing is, this request only need
once,
Then my JMXServer will save the UriInfo and also all the href values in MBean
are fixed, no further change until another server's bounce.
> Please have UriInfo injected in one of the JMXServer's fields, remove
> NPE declaration
>
Done.
I will do a fewer more rounds of testing, and put up the source code again.
Thank you.
Regards:
Shenglin Qiu
> Date: Fri, 20 May 2011 11:39:55 +0100
> Subject: Re: Expose MBeans in CXF
> From: sberyoz...@gmail.com
> To: dabaip...@hotmail.com
> CC: dev@cxf.apache.org
>
> Hi Shenglin
>
> I've removed some XML fragments to make it simpler to read...
>
> > Here is what I have right now:
> >
> >
> >http://localhost:8080/services/jmx/mbean/0";>
> >
> >
> >
>
> OK
>
> >
> > And
> > Request:
> > http://localhost:8080/services/jmx/mbean/0
> > Response:
> > http://localhost:8080/services/jmx/mbean/0";>
> >
> >
> > And so on with others.
>
> Very good.
>
> >
> > However, I have to make http://localhost:8080/services/jmx/ at every time I
> > am trying to do anything further, because I need to use this following
> > function to load up all mbeans along with their /mbean/** unique
> > identifiers, and I think this may not be what you want. Please correct me on
> > this.
> >
> Are you saying that you have to use UriInfo and UriBuilder for
> creating hrefs whenever you need to
> build an MBean representation ?
>
> Perhaps, you may want to keep "http://localhost:8080/services/jmx/";
> parts of hrefs in the map as well, as you suggested on #cxf. This will
> let you avoid recalculating the base values for those MBeans which
> have already been retrieved before. These values may not 'survive' the
> restarts for ex, say a port may've been changed, etc, but I agree it
> may be worth optimizing. I'm not sure if injecting UriInfo via
> constructor can provide a way to get to the base address at the
> JMXServer initialization time - may be worth trying later on...
>
> Please don't spend much time on it right now, because it's more
> important at the moment to try to build a more or less complete
> solution around exposing JMX mbeans over HTTP.
>
> Have a look at it a bit further, and then start focusing on making sure
>
> "http://localhost:8080/services/jmx/mbean/0";, etc, are handled by
> MBeanResource subresource, we can keep adding methods for dealing with
> individual MBeans to JMXServer itself, but having a subresource
> dealing with such requests may be a bit cleaner...
>
>
> > @GET
> > public CxfMBeanCollection traversMBeans(@Context UriInfo uriInfo) throws
> > MalformedObjectNameException, NullPointerException{
> >
> >}
> >
> >
>
> Please have UriInfo injected in one of the JMXServer's fields, remove
> NPE declaration
>
> Cheers, Sergey
> >
> > Thank you.
> >
> > Regards:
> > Shenglin Qiu
> >
> >
> >> Date: Thu, 19 May 2011 17:02:36 +0100
> >> Subject: Re: Expose MBeans in CXF
> >> From: sberyoz...@gmail.com
> >> To: dev@cxf.apache.org
> >>
> >> Every MBean should have a unique id so that we can work with it later
> >> on individually.
> >> 0, 1, 2, 3, n, represents the unique part in the otherwise same URI.
> >> When working with MBeans (when populating MBeans collections, etc) you
> >> need to associate some unique number with every MBean. Have some local
> >> AtomicInteger var, have some map there which will keep pairs like
> >> id: Mbean ref
> >>
> >> and generate 'id' dynamically if none already exists in the map for a
> >> given MBean
> >>
> >> may be it should be
> >>
> >> Map
> >> where String is a canonical name.
> >>
> >> So when later on you process something like
> >> /mbean
RE: Expose MBeans in CXF
Hi Sergey:
I am able to use sub-resource locator and @UriInfo and implement:
class JMXServer:
@Path("/mbean/")
public CxfMBean locateMBean() throws MalformedObjectNameException,
NullPointerException{
UriBuilder uriBuilder =
uriInfo.getBaseUriBuilder().path(this.getClass(), "list");
System.out.println("uriInfo.getPath() = "+uriInfo.getPath());
String key = uriInfo.getPath().substring("mbean/".length());
System.out.println(key);
CxfMBeanCollection cxfMBeans = list();
CxfMBean cxfMBean = cxfMBeans.getCxfMBean(key);
return cxfMBean;
}
class CxfMBeanCollection:
public CxfMBean getCxfMBean(String key){
for(CxfMBean cxfMBean : cxfMBeans){
if(cxfMBean.getId() != null && cxfMBean.getId().equals(key)){
return cxfMBean;
}
}
return null;
}
class CxfMBean:
@GET
@Path("{key}")
public CxfMBean getCxfMBean(@PathParam("key") String key){
if(id != null && id.equals(key)){
return this;
}else{
return null;
}
}
Request:
http://localhost:8080/services/jmx/mbean/5
Response:
http://localhost:8080/services/jmx/mbean/5";>
cxf32436715
"UserServiceImpl"
"{http://server.gsoc.apache.org/}UserServiceImpl";
Bus.Service.Endpoint
org.apache.cxf:bus.id=cxf32436715,port="UserServiceImpl",service="{http://server.gsoc.apache.org/}UserServiceImpl",type=Bus.Service.Endpoint
org.apache.cxf
5
And so on for other mbean with id 1, 3, 4, 5, 6 and response with the same
format
http://localhost:8080/services/jmx/mbean/3";>
cxf32436715
Bus
org.apache.cxf:bus.id=cxf32436715,type=Bus
org.apache.cxf
3
Request:
http://localhost:8080/services/jmx/list
Response:
http://localhost:8080/services/jmx/mbean/5";>
cxf32436715
"UserServiceImpl"
"{http://server.gsoc.apache.org/}UserServiceImpl";
Bus.Service.Endpoint
org.apache.cxf:bus.id=cxf32436715,port="UserServiceImpl",service="{http://server.gsoc.apache.org/}UserServiceImpl",type=Bus.Service.Endpoint
org.apache.cxf
5
http://localhost:8080/services/jmx/mbean/4";>
cxf32436715
"SoapPort"
"{http://org.apache.gsoc.server/Greeter_Soap}SOAPService";
Bus.Service.Endpoint
org.apache.cxf:bus.id=cxf32436715,port="SoapPort",service="{http://org.apache.gsoc.server/Greeter_Soap}SOAPService",type=Bus.Service.Endpoint
org.apache.cxf
4
http://localhost:8080/services/jmx/mbean/3";>
cxf32436715
Bus
org.apache.cxf:bus.id=cxf32436715,type=Bus
org.apache.cxf
3
http://localhost:8080/services/jmx/mbean/1";>
cxf32436715
"CustomerServiceImpl"
"{http://server.gsoc.apache.org/}CustomerServiceImpl";
Bus.Service.Endpoint
org.apache.cxf:bus.id=cxf32436715,port="CustomerServiceImpl",service="{http://server.gsoc.apache.org/}CustomerServiceImpl",type=Bus.Service.Endpoint
org.apache.cxf
1
http://localhost:8080/services/jmx/mbean/6";>
MBeanServerDelegate
JMImplementation:type=MBeanServerDelegate
JMImplementation
6
I will clean up my code a little for the next step.
Thank you.
Regards:
Shenglin Qiu
> Date: Sat, 21 May 2011 16:37:29 +0100
> Subject: Re: Expose MBeans in CXF
> From: sberyoz...@gmail.com
> To: dev@cxf.apache.org
>
> >> Are you saying that you have to use UriInfo and UriBuilder for
> >> creating hrefs whenever you need to
> >> build an MBean representation ?
> >>
> >
> > After everytime server bounces, I need to at first use this url request:
> > http://localhost:8080/services/jmx/, the good thing is, this request only
> > need once,
> >
>
> What do you mean it is needed only once ?
>
> > Then my JMXServer will save the UriInfo and also all the href values in
> > MBean are fixed, no further change until another server's bounce.
> >
>
> I don't under
RE: Expose MBeans in CXF
Hi Sergey:
> > Function 1: (0 - 5 is continuous, no gap)
> > Jmx Server:
> > sub-resource locator
> > http://localhost:8080/services/jmx/mbean/0
> > http://localhost:8080/services/jmx/mbean/1
>
> The id allocation (0, 1, etc) has to be thread safe
Done with:
private synchronized Map getMBeansMap(){
}
My reason not using synchronized block but using synchronized method is:
this guarantees the order on mbeansMap's initialization, so when it's called
by a lot of requests, the followings will have to wait, unit the first one
finished, after that, following requests will see mbeansMap has been
initialized, and simply return mbeansMap without initializing it again.
> http://localhost:8080/services/jmx/objectname/org.apache.cxf:*
> or
> http://localhost:8080/services/jmx/objectname/org.apache.cxf
>
> should also work
>
> >
http://localhost:8080/services/jmx/objectname/org.apache.cxf:*
is working.
> > Due to the URL duplication with /mbean/{id}, I can't put
> > {searchtype}/{query}, so I put things like:
>
> Personally I'd prefer to keep a URI as minimal as possible.
>
> /mbean/{id}
> and
> {searchtype}/{query}
>
> do not duplicate each other given that /mbean/{id} is more specific
> than {searchtype}/{query}.
> Likewise /objectname/{objectname} is more specific than
> {searchtype}/{query}, so consider dropping /search/ part,
> we may have a dedicated /search handler later on.
Done by dedicating each request per method:
@GET
@POST
@Path("/list")
public MBeanCollection list()
@Path("/mbean/")
public MBean locateMBean()
@GET
@POST
@Path("/type/{query}")
public MBeanCollection searchMBeansByType(@PathParam("query") String query)
@GET
@POST
@Path("/port/{query}")
public MBeanCollection searchMBeansByPort(@PathParam("query") String query)
@GET
@POST
@Path("/service/{query}")
public MBeanCollection searchMBeansByService(@PathParam("query") String
query)
@GET
@POST
@Path("/objectname/{objectname}")
public MBeanCollection getComponent(@PathParam("objectname") String
objectname)
I remembered you mentioned to handle Exceptions once, currently I am still
'throws' -ing them out, I will make the try catch block.
Should I also add a new object which display the error or simply return empty?
Thank you very much.
Regards:
Shenglin Qiu
> Date: Tue, 31 May 2011 10:35:36 +0100
> Subject: Re: Expose MBeans in CXF
> From: sberyoz...@gmail.com
> To: dev@cxf.apache.org
>
> Hi Shenglin
>
> Good progress, some comments below
> >
> > Function 1: (0 - 5 is continuous, no gap)
> > Jmx Server:
> > sub-resource locator
> > http://localhost:8080/services/jmx/mbean/0
> > http://localhost:8080/services/jmx/mbean/1
>
> The id allocation (0, 1, etc) has to be thread safe
>
> >
> >
> > Function 2:
> > Note: search by bus.id, bus.id will be changed on every time server had been
> > bounced.
> > http://localhost:8080/services/jmx/objectname/org.apache.cxf:bus.id=cxf28619341,*
> > ...
> that is ok, a user does not have to specify them as you demonstrated
> with queries like
>
> > http://localhost:8080/services/jmx/objectname/org.apache.cxf:port=%22CustomerServiceImpl%22,*
> I guess
>
> http://localhost:8080/services/jmx/objectname/org.apache.cxf:*
> or
> http://localhost:8080/services/jmx/objectname/org.apache.cxf
>
> should also work
>
> >
> >
> > I am only now use 2 methods to fulfill:
> > 1 method for service/{serivce}, port/{port}, type/{type}
> > 1 method for objectname/{objectname}
>
> OK
>
> >
> > Due to the URL duplication with /mbean/{id}, I can't put
> > {searchtype}/{query}, so I put things like:
>
> Personally I'd prefer to keep a URI as minimal as possible.
>
> /mbean/{id}
> and
> {searchtype}/{query}
>
> do not duplicate each other given that /mbean/{id} is more specific
> than {searchtype}/{query}.
> Likewise /objectname/{objectname} is more specific than
> {searchtype}/{query}, so consider dropping /search/ part,
> we may have a dedicated /search handler later on.
>
> The other thing I forgot to mention, please remove all those
> System.out.println, ping me please if you need some help with setting
> up a remote debugging session
>
> Thanks, Sergey
>
> >
> > Thank you so much!
> >
> > Regards:
> > Shenglin Qiu
> >
RE: Expose MBeans in CXF
Hi Sergey:
Project has been synced to Github:
Browser:
https://github.com/dabaipang/services
Git address:
https://dabaip...@github.com/dabaipang/services.git
or
g...@github.com:dabaipang/services.git
Thank you.
Regards:
Shenglin Qiu
> From: dabaip...@hotmail.com
> To: sberyoz...@gmail.com
> CC: dev@cxf.apache.org
> Subject: RE: Expose MBeans in CXF
> Date: Tue, 31 May 2011 11:23:38 -0400
>
>
> Hi Sergey:
>
> > > Function 1: (0 - 5 is continuous, no gap)
> > > Jmx Server:
> > > sub-resource locator
> > > http://localhost:8080/services/jmx/mbean/0
> > > http://localhost:8080/services/jmx/mbean/1
> >
> > The id allocation (0, 1, etc) has to be thread safe
>
> Done with:
> private synchronized Map getMBeansMap(){
>
> }
> My reason not using synchronized block but using synchronized method is:
> this guarantees the order on mbeansMap's initialization, so when it's called
> by a lot of requests, the followings will have to wait, unit the first one
> finished, after that, following requests will see mbeansMap has been
> initialized, and simply return mbeansMap without initializing it again.
>
>
> > http://localhost:8080/services/jmx/objectname/org.apache.cxf:*
> > or
> > http://localhost:8080/services/jmx/objectname/org.apache.cxf
> >
> > should also work
> >
> > >
>
> http://localhost:8080/services/jmx/objectname/org.apache.cxf:*
> is working.
>
> > > Due to the URL duplication with /mbean/{id}, I can't put
> > > {searchtype}/{query}, so I put things like:
> >
> > Personally I'd prefer to keep a URI as minimal as possible.
> >
> > /mbean/{id}
> > and
> > {searchtype}/{query}
> >
> > do not duplicate each other given that /mbean/{id} is more specific
> > than {searchtype}/{query}.
> > Likewise /objectname/{objectname} is more specific than
> > {searchtype}/{query}, so consider dropping /search/ part,
> > we may have a dedicated /search handler later on.
>
> Done by dedicating each request per method:
> @GET
> @POST
> @Path("/list")
> public MBeanCollection list()
>
> @Path("/mbean/")
> public MBean locateMBean()
>
>
> @GET
> @POST
> @Path("/type/{query}")
> public MBeanCollection searchMBeansByType(@PathParam("query") String
> query)
>
>
> @GET
> @POST
> @Path("/port/{query}")
> public MBeanCollection searchMBeansByPort(@PathParam("query") String
> query)
>
>
> @GET
> @POST
> @Path("/service/{query}")
> public MBeanCollection searchMBeansByService(@PathParam("query") String
> query)
>
>
> @GET
> @POST
> @Path("/objectname/{objectname}")
> public MBeanCollection getComponent(@PathParam("objectname") String
> objectname)
>
> I remembered you mentioned to handle Exceptions once, currently I am still
> 'throws' -ing them out, I will make the try catch block.
> Should I also add a new object which display the error or simply return empty?
>
>
> Thank you very much.
>
>
> Regards:
> Shenglin Qiu
>
>
> > Date: Tue, 31 May 2011 10:35:36 +0100
> > Subject: Re: Expose MBeans in CXF
> > From: sberyoz...@gmail.com
> > To: dev@cxf.apache.org
> >
> > Hi Shenglin
> >
> > Good progress, some comments below
> > >
> > > Function 1: (0 - 5 is continuous, no gap)
> > > Jmx Server:
> > > sub-resource locator
> > > http://localhost:8080/services/jmx/mbean/0
> > > http://localhost:8080/services/jmx/mbean/1
> >
> > The id allocation (0, 1, etc) has to be thread safe
> >
> > >
> > >
> > > Function 2:
> > > Note: search by bus.id, bus.id will be changed on every time server had
> > > been
> > > bounced.
> > > http://localhost:8080/services/jmx/objectname/org.apache.cxf:bus.id=cxf28619341,*
> > > ...
> > that is ok, a user does not have to specify them as you demonstrated
> > with queries like
> >
> > > http://localhost:8080/services/jmx/objectname/org.apache.cxf:port=%22CustomerServiceImpl%22,*
> > I guess
> >
> > http://localhost:8080/services/jmx/objectname/org.apache.cxf:*
> > or
> > http://localhost:8080/services/jmx/objectname/org.apache.cxf
> >
> > should also work
> >
> > >
> > >
> > > I am only now use 2 methods to fulfill:
> >
RE: Expose MBeans in CXF
Hi Sergey:
I attached the src and due to I am working on the mvn project only sync to svn,
so I will take some time and sync this to github.
And here is an update on the request:
Self-defined demo inbound service:
http://localhost:8080/services/greeter?wsdl
http://localhost:8080/services/customerservice/customers
http://localhost:8080/services/customerservice/customer/firstname/Lois
http://localhost:8080/services/customerservice/customer/id/1
http://localhost:8080/services/userservice/users
http://localhost:8080/services/userservice/user/1
/**
* Specification:
* Function 1:
*Jmx Server:
*sub-resource locator
*http://localhost:8080/services/jmx/property/id/0
*http://localhost:8080/services/jmx/property/id/1
*...
*
*
*Function 2:
*Note: search by bus.id, bus.id will be changed on every time server had
been bounced.
*http://localhost:8080/services/jmx/objectname/org.apache.cxf:*
*
http://localhost:8080/services/jmx/objectname/org.apache.cxf:bus.id=cxf28619341,*
*...
*
http://localhost:8080/services/jmx/objectname/org.apache.cxf:port=%22CustomerServiceImpl%22,*
*
http://localhost:8080/services/jmx/objectname/org.apache.cxf:bus.id=cxf28619341,port=%22SoapPort%22,type=Bus.Service.Endpoint,*
*
http://localhost:8080/services/jmx/objectname/org.apache.cxf:type=Bus.Service.Endpoint,*
*
http://localhost:8080/services/jmx/objectname/org.apache.cxf:bus.id=cxf28619341,service=%22%7Bhttp%3A%2F%2Fserver.gsoc.apache.org%2F%7DCustomerServiceImpl%22,type=Bus.Service.Endpoint,*
*
http://localhost:8080/services/jmx/objectname/org.apache.cxf:service=%22%7Bhttp%3A%2F%2Fserver.gsoc.apache.org%2F%7DCustomerServiceImpl%22,*
*
*Function 3:
*Search by service:
*
http://localhost:8080/services/jmx/property/service/%7Bhttp:%2F%2Fserver.gsoc.apache.org%2F%7DCustomerServiceImpl
*
http://localhost:8080/services/jmx/property/service/%7Bhttp:%2F%2Fserver.gsoc.apache.org%2F%7DUserServiceImpl
*
* Note, above queries are searching these 2, but replace by url encoding from:
* {http://server.gsoc.apache.org/}UserServiceImpl
* {http://server.gsoc.apache.org/}CustomerServiceImpl
*
*Search by type:
*http://localhost:8080/services/jmx/property/type/Bus.Service.Endpoint
*
*Search by port:
*http://localhost:8080/services/jmx/property/port/UserServiceImpl
*http://localhost:8080/services/jmx/property/port/CustomerServiceImpl
*http://localhost:8080/services/jmx/property/port/SoapPort
*
*Function 4:
*http://localhost:8080/services/jmx/list
*
* */
I will ping you tomorrow morning.
Thank you.
Regards:
Shenglin Qiu
> Date: Wed, 1 Jun 2011 15:32:30 +0100
> Subject: Re: Expose MBeans in CXF
> From: sberyoz...@gmail.com
> To: dev@cxf.apache.org
>
> Hi Shenglin
>
> It's a step in the right direction, thanks, but JMXServer still needs
> to be cleaned up quite a bit.
> - as I said earlier you have 4 big functions basically duplicating
> each other. We can't have a method per every attribute a given MBean
> may have. Have a single function only, max two (one capturing all the
> attributes, another one - dedicated to objectname/{value}).
> - Introduce MBeanResource subresource instead of overloading MBean, it
> will be cleaner and easier to work with
> - as suggested earlier, update the domain MBean and/or MBeanAttribute
> such that you could drop a big chunk of code in JMXServer where
> individual attribute values are set, currently in getMbeanMap (if
> (attrName.equals("service") then/else)). That is because a number of
> attributes is basically unlimited, even though we have some well-known
> ones
>
> - getMBeanMap - this is so complex I can't understand what it does. I
> do understand it returns a thread-safe Map - but I'm finding it
> difficult to understand how the method achieves that. Please remove
> all those synchronized blocks and have ConcurrentHashMap. Have atomic
> integer counter, synchronized exlicitly (in a block) if you prefer,
> and try to get a simple and effective function implemented. Don't make
> the logic of that function dependent on a n
> I don't understand why you use "list" for creating MBean hrefs;
>
> - there's no need for having Mbean.id and MBean.href because
> MBean.href is identifying a given MBean uniquely and thus you could
> use that calculated href as a key.
>
> Thanks, Sergey
>
>
> On Tue, May 31, 2011 at 5:36 PM, Shenglin Qiu wrote:
> >
> > Hi Sergey:
> >
> > Project has been synced to Github:
> >
> > Browser:
> > https://github.com/dabaipang/services
> >
> >
> > Git address:
> > https://dabaip...@github.com/dabaipang/services.git
> > or
> > g...@github.com:dabaipang/services
RE: Expose MBeans in CXF
Hi Sergey:
Sorry for replying a little bit late.
But I reverted the code as you mentioned /mbean/{id} must not be changed.
Code has be synced to github:
https://github.com/dabaipang/services
/**
* Specification:
* Function 1:
*Jmx Server:
*sub-resource locator
*http://localhost:8080/services/jmx/mbean/0
*http://localhost:8080/services/jmx/mbean/1
*...
*
*
*Function 2:
*Note: search by bus.id, bus.id will be changed on every time server had
been bounced.
* http://localhost:8080/services/jmx/objectname/org.apache.cxf:*
*
http://localhost:8080/services/jmx/objectname/org.apache.cxf:bus.id=cxf28619341,*
*...
*
http://localhost:8080/services/jmx/objectname/org.apache.cxf:port=%22CustomerServiceImpl%22,*
*
http://localhost:8080/services/jmx/objectname/org.apache.cxf:bus.id=cxf28619341,port=%22SoapPort%22,type=Bus.Service.Endpoint,*
*
http://localhost:8080/services/jmx/objectname/org.apache.cxf:type=Bus.Service.Endpoint,*
*
http://localhost:8080/services/jmx/objectname/org.apache.cxf:bus.id=cxf28619341,service=%22%7Bhttp%3A%2F%2Fserver.gsoc.apache.org%2F%7DCustomerServiceImpl%22,type=Bus.Service.Endpoint,*
*
http://localhost:8080/services/jmx/objectname/org.apache.cxf:service=%22%7Bhttp%3A%2F%2Fserver.gsoc.apache.org%2F%7DCustomerServiceImpl%22,*
*
*Function 3:
*Search by service:
*
http://localhost:8080/services/jmx/service/%7Bhttp:%2F%2Fserver.gsoc.apache.org%2F%7DCustomerServiceImpl
*
http://localhost:8080/services/jmx/service/%7Bhttp:%2F%2Fserver.gsoc.apache.org%2F%7DUserServiceImpl
*
* Note, above queries are searching these 2, but replace by url encoding from:
* {http://server.gsoc.apache.org/}UserServiceImpl
* {http://server.gsoc.apache.org/}CustomerServiceImpl
*
*Search by type:
*http://localhost:8080/services/jmx/type/Bus.Service.Endpoint
*
*Search by port:
*http://localhost:8080/services/jmx/port/UserServiceImpl
*http://localhost:8080/services/jmx/port/CustomerServiceImpl
*http://localhost:8080/services/jmx/port/SoapPort
*
*Search by domain
*http://localhost:8080/services/jmx/domain/org.apache.cxf
*
*Function 4:
*http://localhost:8080/services/jmx/list
*
* */
Source is also attached.
Thank you very much on the reviewing, I am very dedicated to what you have
mentioned. Though there was a time in last 2 days, I reformatted the code a
little too much:)
Regards:
Shenglin Qiu
> Date: Wed, 8 Jun 2011 10:23:58 +0100
> Subject: Re: Expose MBeans in CXF
> From: sberyoz...@gmail.com
> To: dabaip...@hotmail.com
> CC: dev@cxf.apache.org
>
> Hi Shenglin
>
> I'm not sure if I'm confusing you with the comments I'm making...The
> source has become cleaner, good progress there,
> but I'm not sure what are you doing there at all now.
> Why MBeanCollection has become a subresource ? What happened to our
> /mbean/{id} handler ? Recall, you had a subresource locator method
> dealing with '/mbean/{id}' and you were delegating to MBean to finish
> the processing and the only thing I suggested is to have a dedicated
> MBeanResource handler which I guess should wrap an individual MBean
> and work with it (get its state for now, etc)
>
> What does
>
> http://localhost:8080/services/jmx/property/id/0
>
> mean ?
>
> it has to be
>
> http://localhost:8080/services/jmx/mbean/0
> http://localhost:8080/services/jmx/mbean/1
>
> and MBeanResource needs to deal with these URIs.
>
> Please check my previous email.
> have only
> 1. list all MBeans in org.apache.cxf domain
> /list
> 2. find MBeans in org.apache.cxf domain which have a given attribute value
> /{attribute}/{value}
> 3. find MBeans in org.apache.cxf domain their object names
> /objectname/{objectname}
> 4. get the represenation of the individual MBean (and later update it,
> register event listeners, etc)
> /mbean/{id}
>
> // we haven't discussed it yet - need to be done
> 5. Return the counter statistics
>
> /counters
>
> 6. Counters for a specific endpoint
>
> /counters/{servicename}
>
> Sergey
>
> On Wed, Jun 8, 2011 at 5:46 AM, Shenglin Qiu wrote:
> > Hi Sergey:
> >
> > I attached the src and due to I am working on the mvn project only sync to
> > svn, so I will take some time and sync this to github.
> >
> > And here is an update on the request:
> >
> > Self-defined demo inbound service:
> > http://localhost:8080/services/greeter?wsdl
> > http://localhost:8080/services/customerservice/customers
> > http://localhost:8080/services/customerservice/customer/firstname/Lois
> > http://localhost:8080/services/customerservice/customer/id/1
> > http://localhost:8080/services/userservice/u
RE: Expose MBeans in CXF
Hi Sergey:
Continue from last talk in im,
@Path("/mbean/{id}")
public MBean searchMBeanById(@PathParam("id")String id){
@GET
@Path("/{property}/{value}")
public MBeanCollection searchMBeans(@PathParam("property") String property,
@PathParam("value") String value)
is now working as desired.
What I did wrong is put
@Path("/mbean/")
public MBean searchMBeanById(){
and put {id} in MBeanResource.
Thank you for clarifying this out so hard and finally I make it.
I will wrap things up real quick and give you the email update with src.
Regards:
Shenglin Qiu
> Date: Thu, 9 Jun 2011 13:17:49 +0100
> Subject: Re: Expose MBeans in CXF
> From: sberyoz...@gmail.com
> To: dev@cxf.apache.org
>
> Hi Shenglin
>
> One thing which you are doing well is introducing subresources, given
> that both MBean and MBeanCotellection have become the ones.
> Understanding how subresources work is good in itself. I can see you
> have unique ids allocated to MBeans now. So there's some progress.
> IMHO some more code cleanup is needed.
>
> 1. At this stage please have only a ***single*** subresource,
> intoroduce a dedicated class called MBeanResource which should have
> only a single member, MBean instance. This MBeanResource should only
> have right now setMBean(MBean) and getMBean methods. getMBean method
> should be annotated with @GET.
>
> 2. MBean and MBeanCollection should have no static methods, and no
> JAX-RS resource methods at all. These are plain JAXB beans only.
>
> 3. JMXServer should have:
> - /mbean/{id}
>
> Note, Path value should be '/mbean/{id}'
>
> You should use a captured {id}, such as 0, 1, 2, etc (as opposed
> to manually parsing path segments) for locating MBean, set this MBean
> on a new MBeanResource instance and return MBeanResource,
> MBeanResource.getMBean will complete the processing. we will think
> later on how to keep MBeanResources between requests. The reason I'd
> like a dedicated MBeanResource wrap MBean is because possible
> modifications, update notifications, etc may need to be dealt with and
> thus IMHO it can be cleaner to keep MBean as a plain JAXB bean and
> have a dedicated JMX-aware handler around it as opposed to making
> MBean both JAXB and JMX-aware at the same time.
>
> - /list
>
> - /{property}/{value}
>
> Please note this method, /{property}/{value}, is on JMXServer. Remove
> @Path("") and replace it with /{property}/{value}.
>
> - /objectname/{objectname}
>
> This method should iterate over the existing MBeanCollection only
> without quering the instrumentation manager again.
>
> 3. All the methods should use the same code for accessing the map -
> which is what you already do. Some cleanup is needed there too, but
> for now please address the above
>
> thanks, Sergey
>
>
> On Thu, Jun 9, 2011 at 4:05 AM, Shenglin Qiu wrote:
> > Hi Sergey:
> >
> > Sorry for replying a little bit late.
> > But I reverted the code as you mentioned /mbean/{id} must not be changed.
> >
> > Code has be synced to github:
> > https://github.com/dabaipang/services
> >
> > /**
> > * Specification:
> > * Function 1:
> > *Jmx Server:
> > *sub-resource locator
> > *http://localhost:8080/services/jmx/mbean/0
> > *http://localhost:8080/services/jmx/mbean/1
> > *...
> > *
> > *
> > *Function 2:
> > *Note: search by bus.id, bus.id will be changed on every time server
> > had been bounced.
> > * http://localhost:8080/services/jmx/objectname/org.apache.cxf:*
> > *
> > http://localhost:8080/services/jmx/objectname/org.apache.cxf:bus.id=cxf28619341,*
> > *...
> > *
> > http://localhost:8080/services/jmx/objectname/org.apache.cxf:port=%22CustomerServiceImpl%22,*
> > *
> > http://localhost:8080/services/jmx/objectname/org.apache.cxf:bus.id=cxf28619341,port=%22SoapPort%22,type=Bus.Service.Endpoint,*
> > *
> > http://localhost:8080/services/jmx/objectname/org.apache.cxf:type=Bus.Service.Endpoint,*
> > *
> > http://localhost:8080/services/jmx/objectname/org.apache.cxf:bus.id=cxf28619341,service=%22%7Bhttp%3A%2F%2Fserver.gsoc.apache.org%2F%7DCustomerServiceImpl%22,type=Bus.Service.Endpoint,*
> > *
> > http://localhost:8080/services/jmx/objectname/org.apache.cxf:service=%22%7Bhttp%3A%2F%2Fserver.gsoc.apache.org%2F%7DCustomerServiceImpl%22,*
> > *
> > *Function 3:
> > *Search by service:
> > *
> > http://localhost:8080/services/jmx/service/%7Bhttp:%2F%2Fserver.gsoc.apache.org%2F%7DCustomerServiceImpl
> &
