cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shenglin Qiu <dabaip...@hotmail.com>
Subject RE: Expose MBeans in CXF
Date Tue, 31 May 2011 15:23:38 GMT

Hi Sergey:

> > Function 1: (0 - 5 is continuous, no gap)
> > Jmx Server:
> > sub-resource locator
> > http://localhost:8080/services/jmx/mbean/0
> > http://localhost:8080/services/jmx/mbean/1
> 
> The id allocation (0, 1, etc) has to be thread safe

Done with:
private synchronized Map<String, MBean> getMBeansMap(){
 ....
}
My reason not using synchronized block but using synchronized method is:
this guarantees the order on mbeansMap's initialization,  so when it's called by a lot of
requests, the followings will have to wait, unit the first one finished,  after that, following
requests will see mbeansMap has been initialized, and simply return mbeansMap without initializing
it again.


> http://localhost:8080/services/jmx/objectname/org.apache.cxf:*
> or
> http://localhost:8080/services/jmx/objectname/org.apache.cxf
> 
> should also work
> 
> >

http://localhost:8080/services/jmx/objectname/org.apache.cxf:*
is working.

> > Due to the URL duplication with /mbean/{id}, I can't put
> > {searchtype}/{query}, so I put things like:
> 
> Personally I'd  prefer to keep a URI as minimal as possible.
> 
> /mbean/{id}
> and
> {searchtype}/{query}
> 
> do not duplicate each other given that /mbean/{id} is more specific
> than {searchtype}/{query}.
> Likewise /objectname/{objectname} is more specific than
> {searchtype}/{query}, so consider dropping /search/ part,
> we may have a dedicated /search handler later on.

Done by dedicating each request per method:
    @GET
    @POST
    @Path("/list")
    public MBeanCollection list()

    @Path("/mbean/")
    public MBean locateMBean()


    @GET
    @POST
    @Path("/type/{query}")
    public MBeanCollection searchMBeansByType(@PathParam("query") String query)


    @GET
    @POST
    @Path("/port/{query}")
    public MBeanCollection searchMBeansByPort(@PathParam("query") String query)


    @GET
    @POST
    @Path("/service/{query}")
    public MBeanCollection searchMBeansByService(@PathParam("query") String query)


    @GET
    @POST
    @Path("/objectname/{objectname}")
    public  MBeanCollection getComponent(@PathParam("objectname") String objectname)

I remembered you mentioned to handle Exceptions once, currently I am still 'throws' -ing them
out, I will make the try catch block.
Should I also add a new object which display the error or simply return empty?


Thank you very much.


Regards:
Shenglin Qiu


> Date: Tue, 31 May 2011 10:35:36 +0100
> Subject: Re: Expose MBeans in CXF
> From: sberyozkin@gmail.com
> To: dev@cxf.apache.org
> 
> Hi Shenglin
> 
> Good progress, some comments below
> >
> > Function 1: (0 - 5 is continuous, no gap)
> > Jmx Server:
> > sub-resource locator
> > http://localhost:8080/services/jmx/mbean/0
> > http://localhost:8080/services/jmx/mbean/1
> 
> The id allocation (0, 1, etc) has to be thread safe
> 
> >
> >
> > Function 2:
> > Note: search by bus.id, bus.id will be changed on every time server had been
> > bounced.
> > http://localhost:8080/services/jmx/objectname/org.apache.cxf:bus.id=cxf28619341,*
> > ...
> that is ok, a user does not have to specify them as you demonstrated
> with queries like
> 
> > http://localhost:8080/services/jmx/objectname/org.apache.cxf:port=%22CustomerServiceImpl%22,*
> I guess
> 
> http://localhost:8080/services/jmx/objectname/org.apache.cxf:*
> or
> http://localhost:8080/services/jmx/objectname/org.apache.cxf
> 
> should also work
> 
> >
> >
> > I am only now use 2 methods to fulfill:
> > 1 method for service/{serivce}, port/{port}, type/{type}
> > 1 method for objectname/{objectname}
> 
> OK
> 
> >
> > Due to the URL duplication with /mbean/{id}, I can't put
> > {searchtype}/{query}, so I put things like:
> 
> Personally I'd  prefer to keep a URI as minimal as possible.
> 
> /mbean/{id}
> and
> {searchtype}/{query}
> 
> do not duplicate each other given that /mbean/{id} is more specific
> than {searchtype}/{query}.
> Likewise /objectname/{objectname} is more specific than
> {searchtype}/{query}, so consider dropping /search/ part,
> we may have a dedicated /search handler later on.
> 
> The other thing I forgot to mention, please remove all those
> System.out.println, ping me please if you need some help with setting
> up a remote debugging session
> 
> Thanks, Sergey
> 
> >
> > Thank you so much!
> >
> > Regards:
> > Shenglin Qiu
> >
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message