cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Revised Proposal: GSoC - (CXF-3388) Expose CXF JMX MBeans as the JAX-RS resources‏
Date Tue, 26 Apr 2011 11:17:18 GMT
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 <dabaipang@hotmail.com>
>> wrote:
>> >
>> > Hi Sergey:
>> > I have made some progress according to your last email, due to the size
>> > of
>> > each file, I have to paste some of them below. As you can see, in my
>> > spring
>> > application context, I deployed 2 testing Jax Rs services,
>> > UserServiceImpl
>> > and CustomerServiceImpl, and then I attached my JmxService in each of
>> > those
>> > 2 services, plus, I manually make these 2 services share the same root
>> > path.
>> >
>> > Besides listing all mbeans in
>> >  http://localhost:8080/cxfservice/jaxrs/jmx/list,  I now can add these
>> > in
>> > the URL:
>> >
>> > http://localhost:8080/cxfservice/jaxrs/jmx/component/org.apache.cxf:type=Bus.Service.Endpoint,*
>> >
>> > http://localhost:8080/cxfservice/jaxrs/jmx/component/org.apache.cxf:type=*,*
>> > http://localhost:8080/cxfservice/jaxrs/jmx/component/*:bus.id=*,*
>>
>> Very good
>>
>> > I think I need to get on IRC with you some time, and of course, at
>> > anytime
>> > when you are free.
>>
>> Most of the time I'm on #cxf (not today, we have a bank holiday) -
>> please join whenever you get some time.
>> Ping me privately please about your preferred times.
>>
>> > Sadly sometimes, after coding for some while, I lost the ideas of what I
>> > am
>> > doing and what I need to do. Such as, if I use Jconsole to monitor local
>> > java instance with mbeans exposed, for example, my local jetty, it can
>> > also
>> > show up a lot of interesting stuff, like memory usage and cpu usage in
>> > real
>> > time. But right now, except showing up the definitions of each mbean, I
>> > can't see anything more, and I am not also sure about whether I have
>> > shown
>> > the right mbeans and the right url path you wanted.
>>
>> Thanks for sharing those thoughts. The number of CXF MBeans is limited
>> indeed, but the goal of this project
>> is to make sure JMX MBeans are exposed properly over HTTP, so that
>> that can be accessed easily and presented in a number of formats. If
>> we do it right then in principle we can use the JAX-RS resource you
>> are working upon for exposing even non CXF MBeans, may be Karaf
>> Mbeans, etc, we'll see. Another goal of the project is to try to
>> enhance the existing LogBrowser WebUI, make it a bit richer.
>>
>> Here are some more technical comments, it might not be easy to trace
>> them if get them inlined in the copied beans.xml and files...
>>
>> - What you may want to do is to update InstrumentationManagerImpl to
>> be able to access the underlying MBeanServerConnection and have
>> InstrumentationManagerImpl inject into your JAX-RS resource, thus
>> letting the manager deal with JMS-specific configuration and
>> connection management - please do it a bit later on - not critical
>> right now
>>
>> - Note that users may use JAX-RS only, JAX-WS only, or JAX-RS and
>> JAX-WS endpoints. Assume JAX-RS endpoints have only single root
>> resources for now. The JAX-RS resource you are working upon should
>> work either way. You can't have it added to JAX-WS endpoint, so it
>> should be independent. Also I think it should be able to return the
>> list of endpoints it 'manages', possibly in the form of expanded
>> QNames and list all MBeans which 'belong' to a specific endpoint only.
>>
>> Not sure right now how this JAX-RS server can know about individual
>> endpoints - may be it should have a Bus injected, and the list of
>> expanded QNames, ex, {http://users}UserService, or
>> {http://customers}CustomerService. The server will return to the
>> clients this list: it will let them know it manages
>> {http://users}UserService and {http://customers}CustomerService. This
>> will work for JAX-RS endpoints with multiple root resources too. Next
>> clients will ask for a list of MBeans 'belonging' to say
>> {http://users}UserService. The server will return all MBeans which has
>> something to do with it, including a Bus MBean (which can be relevant
>> to other endpoints too) and Mbeans specific to/scoped by
>> {http://users}UserService.
>>
>> Does it make sense ? What do you think ?
>>
>> Cheers, Sergey
>>
>>
>>
>> >
>> > Thank you very much.
>> > Regards:
>> > Shenglin Qiu
>> >
>



-- 
Sergey Beryozkin

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

Mime
View raw message