cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Expose MBeans in CXF
Date Wed, 18 May 2011 10:38:24 GMT
Hi Shenglin

Well done, you are progressing well.

Note that you don't have to start formatting the updates to the dev
list, it's just
the work as usual, keep it simple please :-). And don't CC to the secretary :-)

Some comments below.

> I am fully upgrade it to 2.4.0, I have some testing phase exceptions
> ocurring even I don't have a test case in maven test src folder. I will
> figure this out later after this doc.
If you are seeing some unrelated test failures when building the trunk
then add '-Pfastinstall'

> The RAR src is attached, hope this 'soap' won't confuse you, it actually has
> 1 soap inbound and 2 restful inbounds. I am always stuck at the naming,
> previous demoserver has been down when I was upgrading, that's another
> story, and I will fix it.

Well, /soapdemo is confusing.
Have the context named as "/services" or "/application" and set the
address of SOAP endpoint as "/soap/greeter" or simply "/greeter" as
you do now.

> Here are the 3 enabled inbound service, including 1 soap webservice and 2
> Restful service:(They are up and running)
> http://localhost:8080/soapdemo/greeter?wsdl
> http://localhost:8080/soapdemo/customerservice/customers
> http://localhost:8080/soapdemo/customerservice/customer/firstname/Lois
> http://localhost:8080/soapdemo/customerservice/customer/id/1
> http://localhost:8080/soapdemo/userservice/users
> http://localhost:8080/soapdemo/userservice/user/1

OK, lets have

> And here is the demo inbound Restful service url which is holding the above
> 3 services MBeans:
> http://localhost:8080/soapdemo/jmx/service/

I think you meant to say:

> http://localhost:8080/soapdemo/jmx

which is the address of your JMX server endpoint which should be changed to say

> which is:
> http://localhost:8080/soapdemo/jmx/service/{}CustomerServiceImpl
> http://localhost:8080/soapdemo/jmx/objectname/org.apache.cxf:type=Bus.Service.Endpoint,*
> http://localhost:8080/soapdemo/jmx/type/Bus.Service.Endpoint
> http://localhost:8080/soapdemo/jmx/list

Ok, so what are you saying is that you can have a list of all MBeans
returned, using "/list" or a list of all MBeans which have a matching
objectname or attribute (such as type, service, port, etc)

I like "http://localhost:8080/soapdemo/jmx/list and
http://localhost:8080/soapdemo/jmx/objectname/" though I think we can
simplify those,  but right now make sure that you have something like
@Path("{attribute}/{value}") for a method which serves /service/*, and
/type/* requests. because 'service' and 'type' are attributes and we
can have many attributes.

> Request:
> http://localhost:8080/soapdemo/jmx/service/
> Note: this is actually an url encoded string which is  from:
> http://localhost:8080/soapdemo/jmx/service/{}CustomerServiceImpl
OK, we should also be able to support


which means get all MBeans which have a service attribute with
namespace equal to ''

> Response:
> <MBeanCollection>
>    <MBeans>
>       <MBean>
> <canonicalName>,port="CustomerServiceImpl",service="{}CustomerServiceImpl",type=Bus.Service.Endpoint</canonicalName>
>          <domain>org.apache.cxf</domain>
> <endpointName>"{}CustomerServiceImpl"</endpointName>
>       </MBean>
>    </MBeans>
> </MBeanCollection>
OK. Please remove MBeanCollection wrapper, you have another wrapper, MBeans.
No need to have quotes around endpointName's value.
How about having MBean representation structured like this:

<!-- this is another representation of canonical's name
This can be ignored for now

This will make it simpler for consumers to understand - we may support
returning canonicalNames only or alternative, structured reps but for
now just have MBean representation updated as suggested.

Now, there's one thing which is missing from the above representation
and it is a link to a resource which will deal with a particular MBean
(possible updates of properties, handling the notifications). We need
to put it all into a more practical surface so it should be something

<MBean href="http://localhost:8080/soapdemo/jmx/mbean/1">
<MBean href="http://localhost:8080/soapdemo/jmx/mbean/2">

where http://localhost:8080/soapdemo/jmx/mbean/1,
http://localhost:8080/soapdemo/jmx/mbean/2, etc, uniquely identify
those individual MBeans only.

So please update MBean class to have "href" attribute (with
@XmlAttribute). Have a '@Context UriInfo uriinfo' field in JMXServer
class. When you create a response for /list or /service/*, etc, use
UriInfo to get to the *base* UriBuilder which will represent a URI
like "http://localhost:8080/soapdemo/jmx". Next add "mbean" and then a
number like 1/2/etc which identifies a particular MBean, may be a
short objectname instead of the compete canonical name, etc, so and
have UriBuilder to return you
'http://localhost:8080/soapdemo/jmx/mbean/1', etc:

String href = builder.path("mbean").path(someUniqueKey).build().toString()

Now, the question is how to handle requests like

Your JMXServer should have a subresource locator, with @Path("mbean")
and without HttpMethod.
This locator will return something like MBeanResource and that class,
at this stage, will have *only*
a single @GET resource method with @Path("{key}") and which will
return the above MBean representaion only, without MBeans wrapper:

GET http://localhost:8080/soapdemo/jmx/mbean/1


<MBean href="http://localhost:8080/soapdemo/jmx/mbean/1">

Having a subresource handly because at the next step we will start
working on dealing with notifications/updatiing properties or invoking
operations somehow when applicable.

Does it make sense ? If you have any questions or suggestions - please
ask them here or ping me on #cxf
I guess we have two weeks or so and then I'd like to discuss how
LogBrowser can be extended to act as a consumer of your JMXServer

I'm removing the rest of your message to make it shorter, everything
you posted there looked OK, those who are interested can check the
previous message if needed for more info.

You are progressing very well.

Thanks, Sergey

> Thank you.
> Regards:
> Shenglin Qiu

View raw message