You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Shenglin Qiu <da...@hotmail.com> on 2011/04/07 15:57:44 UTC

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: sberyozkin@gmail.com
To: dabaipang@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 <da...@hotmail.com>






Proposal Title: Expose CXF JMX MBeans as the JAX-RS resources

Student Name: Shenglin


Apache registered account alias: Travis


Student E-mail: dabaipang@hotmail.com


IM: qslnewyork@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 CSS, images and layout will be provided for a mature look & feel.

    * Start to integrate backend to front end.    -- Heavy coding

Jul 11 - July 15 (Mid-Term Evaluation Deadline)

    *  Code review and revise.    -- Hakerthon.
    *  Work evaluation.


July 16 - August 16 (GSoC Suggested 'Pencil' Down Time)
    * Finish front-end back-end integration  -- Heavy coding.

    * Code review and revise   -- Hakerthon.
    * QA

    * Documentation.

August 16 - August 30 (GSoC 2011 Final Results Announcement)

   * Code revise   -- Heavy coding.
   * Final round QA.

   * Documentation revise.
   * Code submission.


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
Thank you for Sergey's very helpful advising and mentoring.

If everything looks ok, I will send this by the end of tomorrow, April-7-2011.


Regards:

Shenglin Qiu
06/Apr/2011 		 	   		  



-- 
Sergey Beryozkin

Application Integration Division of Talend
http://sberyozkin.blogspot.com
 		 	   		  

Re: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources‏

Posted by Sergey Beryozkin <sb...@gmail.com>.
>
> I'm a bit confused :-). Here is what I meant:
>
> <!-- Custom JAX-RS endpoint -->
>  <jaxrs:server id="userServiceRs" address="/users-rs"
>        xmlns:s="http://users.com/rs"
>        serviceName="s:UserService">
>        <jaxrs:serviceBeans>
>             <ref bean="userService" />
>        </jaxrs:serviceBeans>
> </jaxrs:server>
>
> <!-- Custom JAX-WS endpoint -->
> <jaxws:endpoint id="userServiceWs" address="/users-ws"
>        implementor="#userService"
>        xmlns:s="http://users.com/ws"
>        serviceName="s:UserService"
>        endpointName="s:UserPort"
> />
>
> <!-- this is the JAX-RS resource you are working upon
> <jaxrs:server id="jaxrs-jmx" address="/jmx">
>        <jaxrs:serviceBeans>
>             <ref bean="jaxrsJmxServer" />
>        </jaxrs:serviceBeans>
> </jaxrs:server>
>
> <bean class="org.apache.cxf.management.web.JMXServer">
>    <property name="managedEndpoints">
>         <list>
>            <value>{http://users.com/rs}UserService</value>
>            <value>{http://users.com/ws}UserService</value>
>         </list>
>    </property>
>    <property name="manager" ref="instrumentationManager"/>
> </bean>

I think my idea of injecting the list of expanded qnames is not a good
one at all. Well, may we can do it at some stage later on for dealing
with endpoints located in the other process or bus, but at this stage
it would suffice if a reference to the bus were injected...JMXServer
can register itself as the endpoint  listener and be aware of all
existing and new endpoints

Cheers, Sergey

Re: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources‏

Posted by Sergey Beryozkin <sb...@gmail.com>.
HI Shenglin

>> - 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.

Please, take all my comments with the grain of salt, doubt them, you
already know more than I do about the way MBeans are dealt with in CXF
:-).

>
>> - 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.

We have to make sure CXF has a JAX-RS resource which can expose MBeans
representing JAX-WS and/or JAX-RS endpoints

> 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>
>

Looks good so far - please remove 'CXF' prefixes, and we'll also think
about providing a schema.

>> 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.


Regarding this comment I made earlier, I can see from the pasted XML
fragment that
the canonical names of the endpoint MBeans do have expanded QNames embedded, so
indeed, we can use expanded QNames to let users query for MBeans
representing individual endpoints

>>
> 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 ?
>>

I'm a bit confused :-). Here is what I meant:

<!-- Custom JAX-RS endpoint -->
 <jaxrs:server id="userServiceRs" address="/users-rs"
        xmlns:s="http://users.com/rs"
        serviceName="s:UserService">
        <jaxrs:serviceBeans>
             <ref bean="userService" />
        </jaxrs:serviceBeans>
</jaxrs:server>

<!-- Custom JAX-WS endpoint -->
<jaxws:endpoint id="userServiceWs" address="/users-ws"
        implementor="#userService"
        xmlns:s="http://users.com/ws"
        serviceName="s:UserService"
        endpointName="s:UserPort"
/>

<!-- this is the JAX-RS resource you are working upon
<jaxrs:server id="jaxrs-jmx" address="/jmx">
        <jaxrs:serviceBeans>
             <ref bean="jaxrsJmxServer" />
        </jaxrs:serviceBeans>
</jaxrs:server>

<bean class="org.apache.cxf.management.web.JMXServer">
    <property name="managedEndpoints">
         <list>
            <value>{http://users.com/rs}UserService</value>
            <value>{http://users.com/ws}UserService</value>
         </list>
    </property>
    <property name="manager" ref="instrumentationManager"/>
</bean>

Our JMX server uses injected InstrumentationManager to interact with
MBeanServer (please see Craig's comments - may be
InstrumentationManager can be further enhanced in time too). It lets
users query the list of endpoints it manages, list of all MBeans
related to all those endpoints (see your CXFMBeanCollection) but also
the list of MBeans representing say {http://users.com/rs}UserService
only. If we use the collection fragment above as an example then we
are talking about the last two MBeans only (Bus and Endpoint).

Does that make sense ?

> 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.
>
Congratulations.  I'm glad you liked my input so far but please, don't
praise me given that all I did so far was saying to you 'checkout CXF
source and figure out how things are working' :-). Seriously, lets
focus on the project, you are doing well

Thanks, Sergey

> Regards:
> Shenglin Qiu
>
>
>
>
>> Does it make sense ? What do you think ?
>>
> Due to the large size of cxf, I will follow the steps from you. My thoughts
> could be deviated, so please correct me at any time.
>
> Your mentoring has delighted me since the beginning and it's awesome that I
> have received that confirmation email from google today that I am enrolled.
> Thank you very much.
>
>
>
>> Date: Mon, 25 Apr 2011 16:21:14 +0100
>> Subject: Re: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as
>> the JAX-RS resources‏
>> From: sberyozkin@gmail.com
>> To: dabaipang@hotmail.com
>> CC: dev@cxf.apache.org
>>
>> Hi Shenglin
>>
>> You are progressing very well, please see comments inline
>>
>> On Mon, Apr 25, 2011 at 12:25 AM, Travis Roy <da...@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
>> >
>



-- 
Sergey Beryozkin

Application Integration Division of Talend
http://sberyozkin.blogspot.com

Re: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources‏

Posted by Craig McClanahan <cr...@gmail.com>.
As a heavy user of CXF, Spring, and wanting to leverage JMX more than we
have in the past, one thing you might want to consider is using Spring's
built in support for configuring and manipulating JMX MBeans[1].  If you run
under a servlet container like Tomcat that already provides a JMX
registry[2], life is very simple -- you can define your MBean beans,
attributes, and operations with Spring-provided annotations and all of the
wiring happens for you.  If not using Tomcat, then Spring still provides
easy mechanisms to integrate with any provided MBean server.

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

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

Craig McClanahan

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

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

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

RE: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources‏

Posted by Shenglin Qiu <da...@hotmail.com>.
Hi Sergey:

I pasted your comments with font 10 along with mine with font 12, hope you don't mind :)

> On Mon, Apr 25, 2011 at 12:25 AM, Travis Roy <da...@hotmail.com> wrote:
> >
> > Hi Sergey:
> > I have made some progress according to your last email, due to the size of
> > each file, I have to paste some of them below. As you can see, in my spring
> > application context, I deployed 2 testing Jax Rs services, UserServiceImpl
> > and CustomerServiceImpl, and then I attached my JmxService in each of those
> > 2 services, plus, I manually make these 2 services share the same root path.
> >
> > Besides listing all mbeans in
> >  http://localhost:8080/cxfservice/jaxrs/jmx/list,  I now can add these in
> > the URL:
> > http://localhost:8080/cxfservice/jaxrs/jmx/component/org.apache.cxf:type=Bus.Service.Endpoint,*
> > http://localhost:8080/cxfservice/jaxrs/jmx/component/org.apache.cxf:type=*,*
> > http://localhost:8080/cxfservice/jaxrs/jmx/component/*:bus.id=*,*
>
> Very good
>
> > I think I need to get on IRC with you some time, and of course, at anytime
> > when you are free.
>
> Most of the time I'm on #cxf (not today, we have a bank holiday) -
> please join whenever you get some time.
> Ping me privately please about your preferred times.
>
> > Sadly sometimes, after coding for some while, I lost the ideas of what I am
> > doing and what I need to do. Such as, if I use Jconsole to monitor local
> > java instance with mbeans exposed, for example, my local jetty, it can also
> > show up a lot of interesting stuff, like memory usage and cpu usage in real
> > time. But right now, except showing up the definitions of each mbean, I
> > can't see anything more, and I am not also sure about whether I have shown
> > the right mbeans and the right url path you wanted.
>
> Thanks for sharing those thoughts. The number of CXF MBeans is limited
> indeed, but the goal of this project
> is to make sure JMX MBeans are exposed properly over HTTP, so that
> that can be accessed easily and presented in a number of formats. If
> we do it right then in principle we can use the JAX-RS resource you
> are working upon for exposing even non CXF MBeans, may be Karaf
> Mbeans, etc, we'll see. Another goal of the project is to try to
> enhance the existing LogBrowser WebUI, make it a bit richer.
>
Gwt, I would love to do it.

> Here are some more technical comments, it might not be easy to trace
> them if get them inlined in the copied beans.xml and files...
>
> - What you may want to do is to update InstrumentationManagerImpl to
> be able to access the underlying MBeanServerConnection and have
> InstrumentationManagerImpl inject into your JAX-RS resource, thus
> letting the manager deal with JMS-specific configuration and
> connection management - please do it a bit later on - not critical
> right now
>

Because InstrumentationManagerImpl has an MBServerConnectorFactory which is focusing on create/stop/... an mbean server, adding MBeanServerConnection would make this class also have a client manager function, it's great! I will strictly follow your designs, as I can see it's one of the core in cxf-rs.

> - Note that users may use JAX-RS only, JAX-WS only, or JAX-RS and
> JAX-WS endpoints. Assume JAX-RS endpoints have only single root
> resources for now. The JAX-RS resource you are working upon should
> work either way. You can't have it added to JAX-WS endpoint, so it
> should be independent. Also I think it should be able to return the
> list of endpoints it 'manages', possibly in the form of expanded
> QNames and list all MBeans which 'belong' to a specific endpoint only.
>

Yes, I should only focus on Jax-RS. 
And further Restful returnings, I have things like this, forgot to include this at last email.:
URL:
http://localhost:8080/cxfservice/jaxrs/jmx/component/org.apache.cxf:type=*,*
Return (Forgive me about the poor xml format)
<CxfMBeanCollection>
        <CxfMBeans>
             <CxfMBean>
                   <canonicalName>
                       org.apache.cxf:bus.id=cxf2006079,port="CustomerServiceImpl",service="{http://impl.service.ws.plumchoice.com/}CustomerServiceImpl",type=Bus.Service.Endpoint
                   </canonicalName>
                   <domain>org.apache.cxf</domain>
             </CxfMBean>

             <CxfMBean>
                 <canonicalName>
                       org.apache.cxf:bus.id=cxf2006079,type=Bus
                 </canonicalName>
                 <domain>org.apache.cxf</domain>
            </CxfMBean>

           <CxfMBean>
                 <canonicalName>
                          org.apache.cxf:bus.id=cxf2006079,port="UserServiceImpl",service="{http://impl.service.ws.plumchoice.com/}UserServiceImpl",type=Bus.Service.Endpoint
                 </canonicalName>    
                 <domain>org.apache.cxf</domain>
           </CxfMBean>
       </CxfMBeans>
</CxfMBeanCollection>

> Not sure right now how this JAX-RS server can know about individual
> endpoints - may be it should have a Bus injected, and the list of
> expanded QNames, ex, {http://users}UserService, or
> {http://customers}CustomerService. The server will return to the
> clients this list: it will let them know it manages
> {http://users}UserService and {http://customers}CustomerService. This
> will work for JAX-RS endpoints with multiple root resources too. Next
> clients will ask for a list of MBeans 'belonging' to say
> {http://users}UserService. The server will return all MBeans which has
> something to do with it, including a Bus MBean (which can be relevant
> to other endpoints too) and Mbeans specific to/scoped by
> {http://users}UserService.
>
Actually, I guess there are 2 places to differentiate each of Jax-rs services, which could satisfy the fact that individual endpoint can manage its own mbeans,
First is do something in xml, but I have looked around it, and I find it is literally the core in cxf-rs,  thus very difficult to 'hack in' this configuration.
    <jaxrs:server id="userServiceRs" address="/jaxrs">
        <jaxrs:serviceBeans>
            <ref bean="userService" />
            <ref bean="jmxService" />
        </jaxrs:serviceBeans>
        <jaxrs:extensionMappings>
            <entry key="feed" value="application/atom+xml"/>
            <entry key="json" value="application/json"/>
            <entry key="xml" value="application/xml"/>
            <entry key="html" value="text/html"/>
        </jaxrs:extensionMappings>
        <jaxrs:jmx>
                <jaxrs:bus>cxf</jaxrs:bus>
                <jaxrs:url>service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi<jaxrs:url>
         </jaxrs:jms>
    </jaxrs:server>

Pros are fine integration with spring and neat, Cons are about the difficulties in implementation.

Second is modify the service bean itself to make it looks like:
<bean id="userService" class="com.plumchoice.ws.service.impl.UserServiceImpl">
        <property name="bus" ref="cxf" />      
        <property name="JMXServiceURL" value="service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
</bean>
This is referenced in cxf-rt-management/src/test/resources/managed-spring.xml, and my idea is let each jax-rs service bean to construct its InstrumentationManagerImpl internally:
   <bean id="org.apache.cxf.management.InstrumentationManager" class="org.apache.cxf.management.jmx.InstrumentationManagerImpl">
        <property name="bus" ref="cxf" />
        <property name="enabled" value="true"/>
        <property name="threaded" value="false"/>       
        <property name="daemon" value="false"/>           
        <property name="JMXServiceURL" value="service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
    </bean>
Pros: basic spring context, ease the configuration/implementation compared to 1, Cons: a little amateur compared to 1?


> Does it make sense ? What do you think ?
>
Due to the large size of cxf, I will follow the steps from you. My thoughts could be deviated, so please correct me at any time.

Your mentoring has delighted me since the beginning and it's awesome that I have received that confirmation email from google today that I am enrolled.
Thank you very much.

Regards:
Shenglin Qiu




> Does it make sense ? What do you think ?
>
Due to the large size of cxf, I will follow the steps from you. My thoughts could be deviated, so please correct me at any time.

Your mentoring has delighted me since the beginning and it's awesome that I have received that confirmation email from google today that I am enrolled.
Thank you very much.



> Date: Mon, 25 Apr 2011 16:21:14 +0100
> Subject: Re: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources‏
> From: sberyozkin@gmail.com
> To: dabaipang@hotmail.com
> CC: dev@cxf.apache.org
> 
> Hi Shenglin
> 
> You are progressing very well, please see comments inline
> 
> On Mon, Apr 25, 2011 at 12:25 AM, Travis Roy <da...@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
> >
 		 	   		  

RE: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources‏

Posted by Shenglin Qiu <da...@hotmail.com>.
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: sberyozkin@gmail.com
> To: dabaipang@hotmail.com
> CC: dev@cxf.apache.org
> 
> Hi Shenglin
> 
> You are progressing very well, please see comments inline
> 
> On Mon, Apr 25, 2011 at 12:25 AM, Travis Roy <da...@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
> >
 		 	   		  

Re: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources‏

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Shenglin

You are progressing very well, please see comments inline

On Mon, Apr 25, 2011 at 12:25 AM, Travis Roy <da...@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
>

Re: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources‏

Posted by Travis Roy <da...@hotmail.com>.
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=*,*

I think I need to get on IRC with you some time, and of course, at anytime when you are free.

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.


Thank you very much.

Regards:
Shenglin Qiu


    <bean id="instrumentationManager" class="org.apache.cxf.management.jmx.InstrumentationManagerImpl">
    	<property name="bus" ref="cxf" />
		<property name="enabled" value="true" />
		<property name="JMXServiceURL" value="service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
	</bean>
	
	<!-- Wiring the counter repository --> 
    <bean id="counterRepository" class="org.apache.cxf.management.counters.CounterRepository">
        <property name="bus" ref="cxf" />        
    </bean>
    
    
    <!-- JAX-RS Server 1 -->
    <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:server>

	<!-- JAX-RS Server 2 -->
    <jaxrs:server id="customerServiceRs" address="/jaxrs">
        <jaxrs:serviceBeans>
            <ref bean="customerService" />
            <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:server>
    
    <bean id="userService" class="com.plumchoice.ws.service.impl.UserServiceImpl" />
    <bean id="customerService" class="com.plumchoice.ws.service.impl.CustomerServiceImpl" />
    <bean id="jmxService" class="com.plumchoice.ws.service.impl.JaxRsJMXServiceImpl" />

Here is my Jmx exposer service class:

@Path("/jmx")
@Produces("application/xml")
public class JaxRsJMXServiceImpl implements JaxRsJMXService {
	private static String jmxServerURL = "service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi";
	private static MBeanServerConnection mbsc;
	public JaxRsJMXServiceImpl() throws IOException{
		JMXServiceURL url = new JMXServiceURL(jmxServerURL);
        JMXConnector jmxc = JMXConnectorFactory.connect(url, null);
        mbsc = jmxc.getMBeanServerConnection();
	}
	
	@GET
	@POST
	@Path("/list")
	@Override
	public CxfMBeanCollection list() throws IOException, MalformedObjectNameException, NullPointerException{
        Set<ObjectName> endpointNames = listBusEndpoint();
        CxfMBeanCollection mBeanCollection = new CxfMBeanCollection();
        Set<CxfMBean> mbeans = new HashSet<CxfMBean>();
        
        Iterator<ObjectName> it = endpointNames.iterator();
        while(it.hasNext()){
        	ObjectName objectName = it.next();
        	System.out.println("CanonicalName = "+objectName.getCanonicalName());
        	System.out.println("Domain = "+objectName.getDomain());
        	CxfMBean mbean = new CxfMBean();
        	mbean.setCanonicalName(objectName.getCanonicalName());
        	mbean.setDomain(objectName.getDomain());
        	mbeans.add(mbean);
        	
        	String canonicalKeyList = objectName.getCanonicalKeyPropertyListString();
        	Hashtable<String, String> keyProperties = objectName.getKeyPropertyList();
        	System.out.println("Canoical Key PropertyList = "+canonicalKeyList);
        	Set<Entry<String, String>> keyPropertySet = keyProperties.entrySet();
        	Iterator<Entry<String, String>> keyPropertyIt = keyPropertySet.iterator();
        	while(keyPropertyIt.hasNext()){
        		Entry<String, String> keyPropertyEntry = keyPropertyIt.next();
        		System.out.println("Key Property key = "+keyPropertyEntry.getKey());
        		System.out.println("Key Property value = "+keyPropertyEntry.getValue());
        	}
        }
        mBeanCollection.setCxfMBeans(mbeans);
		return mBeanCollection;
	}
	@GET
	@POST
	@Path("/component/{objectname}")
	@Override
	public  CxfMBeanCollection getComponent(@PathParam("objectname") String objectname) throws IOException,
		MalformedObjectNameException, NullPointerException {
		
		System.out.println("input = "+objectname);
		Set<ObjectName> endpointNames = listGivenBusEndpoint(objectname);
		CxfMBeanCollection mBeanCollection = new CxfMBeanCollection();
        Set<CxfMBean> mbeans = new HashSet<CxfMBean>();
        
        Iterator<ObjectName> it = endpointNames.iterator();
        while(it.hasNext()){
        	ObjectName objectName = it.next();
        	System.out.println("CanonicalName = "+objectName.getCanonicalName());
        	System.out.println("Domain = "+objectName.getDomain());
        	CxfMBean mbean = new CxfMBean();
        	mbean.setCanonicalName(objectName.getCanonicalName());
        	mbean.setDomain(objectName.getDomain());
        	mbeans.add(mbean);
        	
        	String canonicalKeyList = objectName.getCanonicalKeyPropertyListString();
        	Hashtable<String, String> keyProperties = objectName.getKeyPropertyList();
        	System.out.println("Canoical Key PropertyList = "+canonicalKeyList);
        	Set<Entry<String, String>> keyPropertySet = keyProperties.entrySet();
        	Iterator<Entry<String, String>> keyPropertyIt = keyPropertySet.iterator();
        	while(keyPropertyIt.hasNext()){
        		Entry<String, String> keyPropertyEntry = keyPropertyIt.next();
        		System.out.println("Key Property key = "+keyPropertyEntry.getKey());
        		System.out.println("Key Property value = "+keyPropertyEntry.getValue());
        	}
        }
        mBeanCollection.setCxfMBeans(mbeans);
		return mBeanCollection;
	}

	private Set<ObjectName> listBusEndpoint() throws MalformedObjectNameException, NullPointerException, IOException {
		ObjectName queryEndpointName = new ObjectName(ManagementConstants.DEFAULT_DOMAIN_NAME + ":type=Bus.Service.Endpoint,*");
		Set<ObjectName> endpointNames = CastUtils.cast(mbsc.queryNames(queryEndpointName, null));
		return endpointNames;
    }
	
	private Set<ObjectName> listAllEndpoints() throws MalformedObjectNameException, NullPointerException, IOException{
		ObjectName queryEndpointName = new ObjectName(ManagementConstants.DEFAULT_DOMAIN_NAME + ":type=*,*");
		Set<ObjectName> endpointNames = CastUtils.cast(mbsc.queryNames(queryEndpointName, null));
		return endpointNames;
	}
	
	private Set<ObjectName> listAll() throws MalformedObjectNameException, NullPointerException, IOException{
		 ObjectName queryEndpointName = new ObjectName("*:type=*,*");
	     Set<ObjectName> endpointNames = CastUtils.cast(mbsc.queryNames(queryEndpointName, null));
	     return endpointNames;
	}
	
	private Set<ObjectName> listGivenBusEndpoint(String objectname) throws MalformedObjectNameException, NullPointerException, IOException {
		ObjectName queryEndpointName = new ObjectName(objectname);
		Set<ObjectName> endpointNames = CastUtils.cast(mbsc.queryNames(queryEndpointName, null));
		return endpointNames;
    }

On Apr 18, 2011, at 5:54 AM, Sergey Beryozkin wrote:

> Hi
> 
> It is a good progress, I think you are on the right path.
> Just to see that things are really working, introduce ObjectName and
> ManagedComponent JAXB beans which will be initialized from JMX ObjectName
> and ManagedComponent JMX objects.
> 
> That should be enough for GETs to start working. We will think on which HTTP
> verbs to use to start/stop ManageComponents/etc next.
> 
> At this stage just try to get the list of  (JAXB) ObjectNames returned and
> add another method which will return a specific (JAXB) ManagedComponent
> given the query like this:
> 
> GET /jaxrsjms/component/{objectname}
> or
> GET /jaxrsjms/component?name={objectname}
> 
> where {objectname} is one of the returned ObjectNames.
> 
> Cheers, Sergey
> 
> 
> On Sun, Apr 17, 2011 at 12:54 AM, Travis Roy <da...@hotmail.com> wrote:
> 
>> Hi Sergey:
>> 
>> I think i get stuck at the server's returning. Usually, I define my own
>> domain object bound with JAXB annotation, but right now, if I am having this
>> class:
>> 
>> @Path("/jaxrsjmx")
>> @Produces("application/xml")
>> public class JaxRsJMXServiceImpl implements JaxRsJMXService {
>> private static String jmxServerURL =
>> "service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi";
>> private static MBeanServerConnection mbsc;
>> @GET
>> @Path("/list")
>> public Set<ObjectName> list() throws IOException,
>> MalformedObjectNameException, NullPointerException{
>> JMXServiceURL url = new JMXServiceURL(jmxServerURL);
>>        JMXConnector jmxc = JMXConnectorFactory.connect(url, null);
>>        mbsc = jmxc.getMBeanServerConnection();
>>        ObjectName queryEndpointName = new ObjectName(ManagementConstants.
>> DEFAULT_DOMAIN_NAME  + ":type=Bus.Service.Endpoint,*");
>>        Set<ObjectName> endpointNames = CastUtils.cast(mbsc.queryNames(queryEndpointName,
>> null));
>> return endpointNames;
>> }
>> 
>> 
>> @GET
>> @Path("/start")
>> public ManagedComponent start(){
>> System.out.println("/start");
>> return null;
>> }
>> 
>> 
>> 
>> @GET
>> @Path("/stop")
>> public ManagedComponent stop(){
>> System.out.println("/stop");
>> return null;
>> }
>> 
>> 
>> @GET
>> @Path("/restart")
>> public ManagedComponent restart(){
>> System.out.println("/restart");
>> return null;
>> }
>> }
>> 
>> As you can see, this list() function's return is obviously wrong. So far, I
>> can't figure out a way to properly return a cxf mbean or a list of mbeans,
>> though client can reach the above methods.
>> Usually, I have domain object like this
>> 
>> @XmlRootElement(name = "user")
>> public class User {
>> private Integer id;
>> private String userName;
>> private String firstName;
>> private String lastName;
>> public User(){}
>> public User(Integer id, String userName){
>> this.id = id;
>> this.userName = userName;
>> }
>> public Integer getId() {
>> return id;
>> }
>> public void setId(Integer id) {
>> this.id = id;
>> }
>> public String getUserName() {
>> return userName;
>> }
>> public void setUserName(String userName) {
>> this.userName = userName;
>> }
>> public String getFirstName() {
>> return firstName;
>> }
>> public void setFirstName(String firstName) {
>> this.firstName = firstName;
>> }
>> public String getLastName() {
>> return lastName;
>> }
>> public void setLastName(String lastName) {
>> this.lastName = lastName;
>> }
>> }
>> And I can easily return this 'User' back to client in REST, however, I am
>> just guessing how I am able to wrap/apply this pattern on mbeans.
>> 
>> I need your help.
>> Thank you very much.
>> 
>> Here is part of my spring context:
>>     <import resource="classpath:META-INF/cxf/cxf.xml" />
>>    <!-- <import resource="classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml"/>
>> -->
>>    <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
>>    <import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
>>    <import resource=
>> "classpath:META-INF/cxf/cxf-extension-ws-security.xml" />
>>    <import resource="classpath*:META-INF/cxf/cxf-extension-*.xml" />
>>    <!-- Enable message logging using the CXF logging feature -->
>>    <cxf:bus>
>>        <cxf:features>
>>            <cxf:logging/>
>>        </cxf:features>
>>    </cxf:bus>
>>      <bean id="instrumentationManager" class=
>> "org.apache.cxf.management.jmx.InstrumentationManagerImpl">
>>    <property name="bus" ref="cxf" />
>> <property name="enabled" value="true" />
>> <property name="JMXServiceURL" value=
>> "service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
>>  </bean>
>> 
>> 
>> <!-- Wiring the counter repository -->
>>    <bean id="counterRepository" class=
>> "org.apache.cxf.management.counters.CounterRepository">
>>         <property name="bus" ref="cxf" />
>>    </bean>
>> 
>> 
>> 
>> 
>>    <!-- JAX-RS Server -->
>>    <jaxrs:server id="userServiceRs" address="/rest">
>>        <jaxrs:serviceBeans>
>>            <ref bean="userService" />
>>            <ref bean="jmxService" />
>>         </jaxrs:serviceBeans>
>>        <jaxrs:extensionMappings>
>>            <entry key="xml" value="application/xml" />
>>        </jaxrs:extensionMappings>
>>    </jaxrs:server>
>> 
>>    <bean id="userService" class=
>> "com.mycompany.ws.service.impl.UserServiceImpl" />
>>    <bean id="jmxService" class=
>> "com.mycompany.ws.service.impl.JaxRsJMXServiceImpl" />
>> 
>> PS: UserServiceImpl is working totally ok.
>> 
>> 
>> 
>> Regards:
>> Shenglin Qiu
>> 
>> 
>> 
>> 
>> 


Re: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources‏

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi

Introducing a collection wrapper is a not a bad idea - WADL will generate an
element for it, but it is not strictly needed. I was just suggesting to
introduce *our own* ObjectName wrapper, a bean which will only have a String
property initialized from JMX ObjectName.

Introducing a custom JAX-RS MessageBodyWriter which will handle JMX
ObjectName/etc can also work, but no schema will be generated in that
case...

Cheers, Sergey
On Mon, Apr 18, 2011 at 2:35 PM, Travis Roy <da...@hotmail.com> wrote:

>  Yes, Sergey.
>
> I am trying to do this, but so far, can't get rid of the replying on must
> have @XmlRootElement annotation for ObjectName. Probably, I need to create
> some testing purpose mbeans, register to InstrumentationManagerImpl, and see
> how they work.
>
>
>  @XmlRootElement
> public class ObjectNameCollection {
> private Set<ObjectName> endPointNames;
>
> @XmlElement(name="endpoint")
> @XmlElementWrapper(name="endpoints")
> public Set<ObjectName> getEndPointNames() {
> return endPointNames;
> }
>
> public void setEndPointNames(Set<ObjectName> endPointNames) {
> this.endPointNames = endPointNames;
> }
> }
>
>  @GET
> @Path("/list")
> public ObjectNameCollection list() throws IOException,
> MalformedObjectNameException, NullPointerException{
>  JMXServiceURL url = new JMXServiceURL(jmxServerURL);
>         JMXConnector jmxc = JMXConnectorFactory.connect(url, null);
>         mbsc = jmxc.getMBeanServerConnection();
>         ObjectName queryEndpointName = new ObjectName(ManagementConstants.
> DEFAULT_DOMAIN_NAME  + ":type=Bus.Service.Endpoint,*");
>         Set<ObjectName> endpointNames = CastUtils.cast(mbsc.queryNames(queryEndpointName,
> null));
>         ObjectNameCollection objNameCollection = newObjectNameCollection();
>         objNameCollection.setEndPointNames(endpointNames);
>         Iterator<ObjectName> it = endpointNames.iterator();
>         while(it.hasNext()){
>         ObjectName objectName = it.next();
>         System.out.println("CanonicalName = "
> +objectName.getCanonicalName());
>         System.out.println("Domain = "+objectName.getDomain());
>         }
> return objNameCollection;
> }
>
>  Another question is, are these all the cxf registered mbeans, (In *All
> known Implementing Classes*) ?
>   org.apache.cxf.management
> Interface ManagedComponent *All Known Subinterfaces:* Counter<http://cxf.apache.org/apidocs/org/apache/cxf/management/counters/Counter.html>
> *All Known Implementing Classes:* ManagedBus<http://cxf.apache.org/apidocs/org/apache/cxf/bus/ManagedBus.html>
> , ManagedEndpoint<http://cxf.apache.org/apidocs/org/apache/cxf/endpoint/ManagedEndpoint.html>
> , PerformanceCounter<http://cxf.apache.org/apidocs/org/apache/cxf/management/counters/PerformanceCounter.html>
> , ResponseTimeCounter<http://cxf.apache.org/apidocs/org/apache/cxf/management/counters/ResponseTimeCounter.html>
> , WorkQueueImplMBeanWrapper<http://cxf.apache.org/apidocs/org/apache/cxf/workqueue/WorkQueueImplMBeanWrapper.html>
> , WorkQueueManagerImplMBeanWrapper<http://cxf.apache.org/apidocs/org/apache/cxf/workqueue/WorkQueueManagerImplMBeanWrapper.html>
>
>
> Regards
> Shenglin Qiu
>
>
>
>
>
>
>
>  On Apr 18, 2011, at 5:54 AM, Sergey Beryozkin wrote:
>
>  Hi
>
> It is a good progress, I think you are on the right path.
> Just to see that things are really working, introduce ObjectName and
> ManagedComponent JAXB beans which will be initialized from JMX ObjectName
> and ManagedComponent JMX objects.
>
> That should be enough for GETs to start working. We will think on which
> HTTP
> verbs to use to start/stop ManageComponents/etc next.
>
> At this stage just try to get the list of  (JAXB) ObjectNames returned and
> add another method which will return a specific (JAXB) ManagedComponent
> given the query like this:
>
> GET /jaxrsjms/component/{objectname}
> or
> GET /jaxrsjms/component?name={objectname}
>
> where {objectname} is one of the returned ObjectNames.
>
> Cheers, Sergey
>
>
> On Sun, Apr 17, 2011 at 12:54 AM, Travis Roy <da...@hotmail.com>
> wrote:
>
> Hi Sergey:
>
>
> I think i get stuck at the server's returning. Usually, I define my own
>
> domain object bound with JAXB annotation, but right now, if I am having
> this
>
> class:
>
>
> @Path("/jaxrsjmx")
>
> @Produces("application/xml")
>
> public class JaxRsJMXServiceImpl implements JaxRsJMXService {
>
> private static String jmxServerURL =
>
> "service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi";
>
> private static MBeanServerConnection mbsc;
>
> @GET
>
> @Path("/list")
>
> public Set<ObjectName> list() throws IOException,
>
> MalformedObjectNameException, NullPointerException{
>
> JMXServiceURL url = new JMXServiceURL(jmxServerURL);
>
>        JMXConnector jmxc = JMXConnectorFactory.connect(url, null);
>
>        mbsc = jmxc.getMBeanServerConnection();
>
>        ObjectName queryEndpointName = new ObjectName(ManagementConstants.
>
> DEFAULT_DOMAIN_NAME  + ":type=Bus.Service.Endpoint,*");
>
>        Set<ObjectName> endpointNames =
> CastUtils.cast(mbsc.queryNames(queryEndpointName,
>
> null));
>
> return endpointNames;
>
> }
>
>
>
> @GET
>
> @Path("/start")
>
> public ManagedComponent start(){
>
> System.out.println("/start");
>
> return null;
>
> }
>
>
>
>
> @GET
>
> @Path("/stop")
>
> public ManagedComponent stop(){
>
> System.out.println("/stop");
>
> return null;
>
> }
>
>
>
> @GET
>
> @Path("/restart")
>
> public ManagedComponent restart(){
>
> System.out.println("/restart");
>
> return null;
>
> }
>
> }
>
>
> As you can see, this list() function's return is obviously wrong. So far, I
>
> can't figure out a way to properly return a cxf mbean or a list of mbeans,
>
> though client can reach the above methods.
>
> Usually, I have domain object like this
>
>
> @XmlRootElement(name = "user")
>
> public class User {
>
> private Integer id;
>
> private String userName;
>
> private String firstName;
>
> private String lastName;
>
> public User(){}
>
> public User(Integer id, String userName){
>
> this.id = id;
>
> this.userName = userName;
>
> }
>
> public Integer getId() {
>
> return id;
>
> }
>
> public void setId(Integer id) {
>
> this.id = id;
>
> }
>
> public String getUserName() {
>
> return userName;
>
> }
>
> public void setUserName(String userName) {
>
> this.userName = userName;
>
> }
>
> public String getFirstName() {
>
> return firstName;
>
> }
>
> public void setFirstName(String firstName) {
>
> this.firstName = firstName;
>
> }
>
> public String getLastName() {
>
> return lastName;
>
> }
>
> public void setLastName(String lastName) {
>
> this.lastName = lastName;
>
> }
>
> }
>
> And I can easily return this 'User' back to client in REST, however, I am
>
> just guessing how I am able to wrap/apply this pattern on mbeans.
>
>
> I need your help.
>
> Thank you very much.
>
>
> Here is part of my spring context:
>
>     <import resource="classpath:META-INF/cxf/cxf.xml" />
>
>    <!-- <import
> resource="classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml"/>
>
> -->
>
>    <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
>
>    <import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
>
>    <import resource=
>
> "classpath:META-INF/cxf/cxf-extension-ws-security.xml" />
>
>    <import resource="classpath*:META-INF/cxf/cxf-extension-*.xml" />
>
>    <!-- Enable message logging using the CXF logging feature -->
>
>    <cxf:bus>
>
>        <cxf:features>
>
>            <cxf:logging/>
>
>        </cxf:features>
>
>    </cxf:bus>
>
>      <bean id="instrumentationManager" class=
>
> "org.apache.cxf.management.jmx.InstrumentationManagerImpl">
>
>    <property name="bus" ref="cxf" />
>
> <property name="enabled" value="true" />
>
> <property name="JMXServiceURL" value=
>
> "service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
>
>  </bean>
>
>
>
> <!-- Wiring the counter repository -->
>
>    <bean id="counterRepository" class=
>
> "org.apache.cxf.management.counters.CounterRepository">
>
>         <property name="bus" ref="cxf" />
>
>    </bean>
>
>
>
>
>
>    <!-- JAX-RS Server -->
>
>    <jaxrs:server id="userServiceRs" address="/rest">
>
>        <jaxrs:serviceBeans>
>
>            <ref bean="userService" />
>
>            <ref bean="jmxService" />
>
>         </jaxrs:serviceBeans>
>
>        <jaxrs:extensionMappings>
>
>            <entry key="xml" value="application/xml" />
>
>        </jaxrs:extensionMappings>
>
>    </jaxrs:server>
>
>
>    <bean id="userService" class=
>
> "com.mycompany.ws.service.impl.UserServiceImpl" />
>
>    <bean id="jmxService" class=
>
> "com.mycompany.ws.service.impl.JaxRsJMXServiceImpl" />
>
>
> PS: UserServiceImpl is working totally ok.
>
>
>
>
> Regards:
>
> Shenglin Qiu
>
>
>
>
>
>
>
>


-- 
Sergey Beryozkin

Application Integration Division of Talend <http://www.talend.com/>
http://sberyozkin.blogspot.com

Re: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources‏

Posted by Travis Roy <da...@hotmail.com>.
Yes, Sergey.

I am trying to do this, but so far, can't get rid of the replying on must have @XmlRootElement annotation for ObjectName. Probably, I need to create some testing purpose mbeans, register to InstrumentationManagerImpl, and see how they work.

 
@XmlRootElement
public class ObjectNameCollection {
	private Set<ObjectName> endPointNames;

	@XmlElement(name="endpoint")
	@XmlElementWrapper(name="endpoints")
	public Set<ObjectName> getEndPointNames() {
		return endPointNames;
	}

	public void setEndPointNames(Set<ObjectName> endPointNames) {
		this.endPointNames = endPointNames;
	}
}

@GET
@Path("/list")
public ObjectNameCollection list() throws IOException, MalformedObjectNameException, NullPointerException{
		JMXServiceURL url = new JMXServiceURL(jmxServerURL);
        JMXConnector jmxc = JMXConnectorFactory.connect(url, null);
        mbsc = jmxc.getMBeanServerConnection();
        ObjectName queryEndpointName = new ObjectName(ManagementConstants.DEFAULT_DOMAIN_NAME  + ":type=Bus.Service.Endpoint,*");
        Set<ObjectName> endpointNames = CastUtils.cast(mbsc.queryNames(queryEndpointName, null));
        ObjectNameCollection objNameCollection = new ObjectNameCollection();
        objNameCollection.setEndPointNames(endpointNames);
        Iterator<ObjectName> it = endpointNames.iterator();
        while(it.hasNext()){
        	ObjectName objectName = it.next();
        	System.out.println("CanonicalName = "+objectName.getCanonicalName());
        	System.out.println("Domain = "+objectName.getDomain());
        }
		return objNameCollection;
}

Another question is, are these all the cxf registered mbeans, (In All known Implementing Classes) ?
 org.apache.cxf.management 
Interface ManagedComponent

All Known Subinterfaces:
Counter
All Known Implementing Classes:
ManagedBus, ManagedEndpoint, PerformanceCounter, ResponseTimeCounter, WorkQueueImplMBeanWrapper, WorkQueueManagerImplMBeanWrapper



Regards
Shenglin Qiu







On Apr 18, 2011, at 5:54 AM, Sergey Beryozkin wrote:

> Hi
> 
> It is a good progress, I think you are on the right path.
> Just to see that things are really working, introduce ObjectName and
> ManagedComponent JAXB beans which will be initialized from JMX ObjectName
> and ManagedComponent JMX objects.
> 
> That should be enough for GETs to start working. We will think on which HTTP
> verbs to use to start/stop ManageComponents/etc next.
> 
> At this stage just try to get the list of  (JAXB) ObjectNames returned and
> add another method which will return a specific (JAXB) ManagedComponent
> given the query like this:
> 
> GET /jaxrsjms/component/{objectname}
> or
> GET /jaxrsjms/component?name={objectname}
> 
> where {objectname} is one of the returned ObjectNames.
> 
> Cheers, Sergey
> 
> 
> On Sun, Apr 17, 2011 at 12:54 AM, Travis Roy <da...@hotmail.com> wrote:
> 
>> Hi Sergey:
>> 
>> I think i get stuck at the server's returning. Usually, I define my own
>> domain object bound with JAXB annotation, but right now, if I am having this
>> class:
>> 
>> @Path("/jaxrsjmx")
>> @Produces("application/xml")
>> public class JaxRsJMXServiceImpl implements JaxRsJMXService {
>> private static String jmxServerURL =
>> "service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi";
>> private static MBeanServerConnection mbsc;
>> @GET
>> @Path("/list")
>> public Set<ObjectName> list() throws IOException,
>> MalformedObjectNameException, NullPointerException{
>> JMXServiceURL url = new JMXServiceURL(jmxServerURL);
>>        JMXConnector jmxc = JMXConnectorFactory.connect(url, null);
>>        mbsc = jmxc.getMBeanServerConnection();
>>        ObjectName queryEndpointName = new ObjectName(ManagementConstants.
>> DEFAULT_DOMAIN_NAME  + ":type=Bus.Service.Endpoint,*");
>>        Set<ObjectName> endpointNames = CastUtils.cast(mbsc.queryNames(queryEndpointName,
>> null));
>> return endpointNames;
>> }
>> 
>> 
>> @GET
>> @Path("/start")
>> public ManagedComponent start(){
>> System.out.println("/start");
>> return null;
>> }
>> 
>> 
>> 
>> @GET
>> @Path("/stop")
>> public ManagedComponent stop(){
>> System.out.println("/stop");
>> return null;
>> }
>> 
>> 
>> @GET
>> @Path("/restart")
>> public ManagedComponent restart(){
>> System.out.println("/restart");
>> return null;
>> }
>> }
>> 
>> As you can see, this list() function's return is obviously wrong. So far, I
>> can't figure out a way to properly return a cxf mbean or a list of mbeans,
>> though client can reach the above methods.
>> Usually, I have domain object like this
>> 
>> @XmlRootElement(name = "user")
>> public class User {
>> private Integer id;
>> private String userName;
>> private String firstName;
>> private String lastName;
>> public User(){}
>> public User(Integer id, String userName){
>> this.id = id;
>> this.userName = userName;
>> }
>> public Integer getId() {
>> return id;
>> }
>> public void setId(Integer id) {
>> this.id = id;
>> }
>> public String getUserName() {
>> return userName;
>> }
>> public void setUserName(String userName) {
>> this.userName = userName;
>> }
>> public String getFirstName() {
>> return firstName;
>> }
>> public void setFirstName(String firstName) {
>> this.firstName = firstName;
>> }
>> public String getLastName() {
>> return lastName;
>> }
>> public void setLastName(String lastName) {
>> this.lastName = lastName;
>> }
>> }
>> And I can easily return this 'User' back to client in REST, however, I am
>> just guessing how I am able to wrap/apply this pattern on mbeans.
>> 
>> I need your help.
>> Thank you very much.
>> 
>> Here is part of my spring context:
>>     <import resource="classpath:META-INF/cxf/cxf.xml" />
>>    <!-- <import resource="classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml"/>
>> -->
>>    <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
>>    <import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
>>    <import resource=
>> "classpath:META-INF/cxf/cxf-extension-ws-security.xml" />
>>    <import resource="classpath*:META-INF/cxf/cxf-extension-*.xml" />
>>    <!-- Enable message logging using the CXF logging feature -->
>>    <cxf:bus>
>>        <cxf:features>
>>            <cxf:logging/>
>>        </cxf:features>
>>    </cxf:bus>
>>      <bean id="instrumentationManager" class=
>> "org.apache.cxf.management.jmx.InstrumentationManagerImpl">
>>    <property name="bus" ref="cxf" />
>> <property name="enabled" value="true" />
>> <property name="JMXServiceURL" value=
>> "service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
>>  </bean>
>> 
>> 
>> <!-- Wiring the counter repository -->
>>    <bean id="counterRepository" class=
>> "org.apache.cxf.management.counters.CounterRepository">
>>         <property name="bus" ref="cxf" />
>>    </bean>
>> 
>> 
>> 
>> 
>>    <!-- JAX-RS Server -->
>>    <jaxrs:server id="userServiceRs" address="/rest">
>>        <jaxrs:serviceBeans>
>>            <ref bean="userService" />
>>            <ref bean="jmxService" />
>>         </jaxrs:serviceBeans>
>>        <jaxrs:extensionMappings>
>>            <entry key="xml" value="application/xml" />
>>        </jaxrs:extensionMappings>
>>    </jaxrs:server>
>> 
>>    <bean id="userService" class=
>> "com.mycompany.ws.service.impl.UserServiceImpl" />
>>    <bean id="jmxService" class=
>> "com.mycompany.ws.service.impl.JaxRsJMXServiceImpl" />
>> 
>> PS: UserServiceImpl is working totally ok.
>> 
>> 
>> 
>> Regards:
>> Shenglin Qiu
>> 
>> 
>> 
>> 
>> 


Re: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources‏

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi

It is a good progress, I think you are on the right path.
Just to see that things are really working, introduce ObjectName and
ManagedComponent JAXB beans which will be initialized from JMX ObjectName
and ManagedComponent JMX objects.

That should be enough for GETs to start working. We will think on which HTTP
verbs to use to start/stop ManageComponents/etc next.

At this stage just try to get the list of  (JAXB) ObjectNames returned and
add another method which will return a specific (JAXB) ManagedComponent
given the query like this:

GET /jaxrsjms/component/{objectname}
or
 GET /jaxrsjms/component?name={objectname}

where {objectname} is one of the returned ObjectNames.

Cheers, Sergey


On Sun, Apr 17, 2011 at 12:54 AM, Travis Roy <da...@hotmail.com> wrote:

>  Hi Sergey:
>
> I think i get stuck at the server's returning. Usually, I define my own
> domain object bound with JAXB annotation, but right now, if I am having this
> class:
>
>  @Path("/jaxrsjmx")
> @Produces("application/xml")
> public class JaxRsJMXServiceImpl implements JaxRsJMXService {
> private static String jmxServerURL =
> "service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi";
> private static MBeanServerConnection mbsc;
> @GET
> @Path("/list")
> public Set<ObjectName> list() throws IOException,
> MalformedObjectNameException, NullPointerException{
> JMXServiceURL url = new JMXServiceURL(jmxServerURL);
>         JMXConnector jmxc = JMXConnectorFactory.connect(url, null);
>         mbsc = jmxc.getMBeanServerConnection();
>         ObjectName queryEndpointName = new ObjectName(ManagementConstants.
> DEFAULT_DOMAIN_NAME  + ":type=Bus.Service.Endpoint,*");
>         Set<ObjectName> endpointNames = CastUtils.cast(mbsc.queryNames(queryEndpointName,
> null));
> return endpointNames;
> }
>
>
> @GET
> @Path("/start")
> public ManagedComponent start(){
> System.out.println("/start");
> return null;
> }
>
>
>
> @GET
> @Path("/stop")
> public ManagedComponent stop(){
> System.out.println("/stop");
> return null;
> }
>
>
> @GET
> @Path("/restart")
> public ManagedComponent restart(){
> System.out.println("/restart");
> return null;
> }
> }
>
> As you can see, this list() function's return is obviously wrong. So far, I
> can't figure out a way to properly return a cxf mbean or a list of mbeans,
> though client can reach the above methods.
> Usually, I have domain object like this
>
>  @XmlRootElement(name = "user")
> public class User {
> private Integer id;
> private String userName;
> private String firstName;
> private String lastName;
> public User(){}
> public User(Integer id, String userName){
> this.id = id;
> this.userName = userName;
> }
> public Integer getId() {
> return id;
> }
> public void setId(Integer id) {
> this.id = id;
> }
> public String getUserName() {
> return userName;
> }
> public void setUserName(String userName) {
> this.userName = userName;
> }
> public String getFirstName() {
> return firstName;
> }
> public void setFirstName(String firstName) {
> this.firstName = firstName;
> }
> public String getLastName() {
> return lastName;
> }
> public void setLastName(String lastName) {
> this.lastName = lastName;
> }
> }
> And I can easily return this 'User' back to client in REST, however, I am
> just guessing how I am able to wrap/apply this pattern on mbeans.
>
> I need your help.
> Thank you very much.
>
> Here is part of my spring context:
>      <import resource="classpath:META-INF/cxf/cxf.xml" />
>     <!-- <import resource="classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml"/>
> -->
>     <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
>     <import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
>     <import resource=
> "classpath:META-INF/cxf/cxf-extension-ws-security.xml" />
>     <import resource="classpath*:META-INF/cxf/cxf-extension-*.xml" />
>     <!-- Enable message logging using the CXF logging feature -->
>     <cxf:bus>
>         <cxf:features>
>             <cxf:logging/>
>         </cxf:features>
>     </cxf:bus>
>       <bean id="instrumentationManager" class=
> "org.apache.cxf.management.jmx.InstrumentationManagerImpl">
>     <property name="bus" ref="cxf" />
> <property name="enabled" value="true" />
> <property name="JMXServiceURL" value=
> "service:jmx:rmi:///jndi/rmi://localhost:9914/jmxrmi" />
>   </bean>
>
>
> <!-- Wiring the counter repository -->
>     <bean id="counterRepository" class=
> "org.apache.cxf.management.counters.CounterRepository">
>          <property name="bus" ref="cxf" />
>     </bean>
>
>
>
>
>     <!-- JAX-RS Server -->
>     <jaxrs:server id="userServiceRs" address="/rest">
>         <jaxrs:serviceBeans>
>             <ref bean="userService" />
>             <ref bean="jmxService" />
>          </jaxrs:serviceBeans>
>         <jaxrs:extensionMappings>
>             <entry key="xml" value="application/xml" />
>         </jaxrs:extensionMappings>
>     </jaxrs:server>
>
>     <bean id="userService" class=
> "com.mycompany.ws.service.impl.UserServiceImpl" />
>     <bean id="jmxService" class=
> "com.mycompany.ws.service.impl.JaxRsJMXServiceImpl" />
>
> PS: UserServiceImpl is working totally ok.
>
>
>
> Regards:
> Shenglin Qiu
>
>
>
>
>

Re: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources‏

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi, thanks for submitting the proposal, I left one comment there, just to
clarify that JConsole will only help you initially, but HTTP-enabled
consumers (browsers or JAX-RS clients) is what will be used to test the
progress.

Understanding JAX-RS concepts and analyzing the blog posts linked to from
CXF-3388 can also be listed as one of the prerequisites

Cheers, Sergey

2011/4/7 Shenglin Qiu <da...@hotmail.com>

>
> 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: sberyozkin@gmail.com
> To: dabaipang@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 <da...@hotmail.com>
>
>
>
>
>
>
> Proposal Title: Expose CXF JMX MBeans as the JAX-RS resources
>
> Student Name: Shenglin
>
>
> Apache registered account alias: Travis
>
>
> Student E-mail: dabaipang@hotmail.com
>
>
> IM: qslnewyork@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 CSS, images and
> layout will be provided for a mature look & feel.
>
>    * Start to integrate backend to front end.    -- Heavy coding
>
> Jul 11 - July 15 (Mid-Term Evaluation Deadline)
>
>    *  Code review and revise.    -- Hakerthon.
>    *  Work evaluation.
>
>
> July 16 - August 16 (GSoC Suggested 'Pencil' Down Time)
>    * Finish front-end back-end integration  -- Heavy coding.
>
>    * Code review and revise   -- Hakerthon.
>    * QA
>
>    * Documentation.
>
> August 16 - August 30 (GSoC 2011 Final Results Announcement)
>
>   * Code revise   -- Heavy coding.
>   * Final round QA.
>
>   * Documentation revise.
>   * Code submission.
>
>
> 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
> Thank you for Sergey's very helpful advising and mentoring.
>
> If everything looks ok, I will send this by the end of tomorrow,
> April-7-2011.
>
>
> Regards:
>
> Shenglin Qiu
> 06/Apr/2011
>
>
>
> --
> Sergey Beryozkin
>
> Application Integration Division of Talend
> http://sberyozkin.blogspot.com
>
>



-- 
Sergey Beryozkin

Application Integration Division of Talend <http://www.talend.com>
http://sberyozkin.blogspot.com