cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Soltysik, Seumas" <>
Subject RE: Managing Features via JMX
Date Tue, 01 May 2007 15:08:40 GMT
Hi Dan,
Answers inline.

-----Original Message-----
From: Dan Diephouse []
Sent: Monday, April 30, 2007 4:43 PM
Subject: Re: Managing Features via JMX

Hi Seumas,

On 4/30/07, Soltysik, Seumas <> wrote:
> I am just coming up to speed on the use of Features in CXF and I like the
> concept of having a single class responsible for managing all the pieces of
> a particular behaviour. What would make this feature even better would be to
> create the infrastructure to manage these features via JMX. So for instance
> if I had a series of interceptors that comprised a performance metrics
> feature, I would like to be able to toggle this capability on an off at
> runtime. Currently the AbstractFeature class does not have the appropriate
> life-cycle methods for doing this. It would be good if there was a
> toggleFeature() method or a turnOffFeature() method. This might need to be
> accompanied by a reinitialize() method as well.

What about enable/disable(Client/Server, Bus)? I'm a bit nervous about
making such a name change between 2.0-RC and 2.0 final, but I know of only
one person who's been using the feature stuff outside of CXF at the moment.
Otherwise we could just add a disable() method.

I am fine with adding a disable() method. What about an enable() method? It seems redundant
to initialize, but once a Feature has been initialized, should a user have to call initialize()
again, passing in a Bus, etc. or should the feature simple hold onto the Bus,etc. obtained
by the initialize() method.

In addition, it would be nice if a user could dynamically deploy a feature
> at runtime even if it had not previously been deployed. The key to doing
> this would be to be able to get access the Spring ApplicationContext and
> pass it a Spring configuration file, url, etc. in order to create the
> Feature. Once the user had a handle to the feature they could initialize it
> with the desired InterceptorProvider.

If you add a feature to your spring file its certain available for you to
use/inject into your app. Otherwise you can just use the API as well...

Perhaps I am asking for too much at this point, but it would be great to be able to dynamically
deploy Features via JMX. At this point it appears that Features need to be included in configuration
at startup in order to be deployed. It would be nice if there was something like a FeatureFactory,
that a user could pass an XML snippet along with an InterceptorProvider that would return
an initialized Feature. But like I said this may be more appropriate down the road.

On a slight tangent, there have been many times that I would have liked to
> have access the the Spring ApplicationContext at runtime. What about making
> the Spring ApplicationContext available via a Bus extensor?

Ewwww :-)

Also from a management perspective it would be nice to be able to query what
> Features were currently deployed to an InterceptorProvidor. This might
> require adding a getName() method to the AbstractFeature class in order for
> a user to identify the particular desired feature.

I wouldn't be opposed to a getName(). It might be worthwhile to consider
using the Spring ID if its managed by Spring.

Speaking of which, lets say I create a feature via the API and not spring
and apply it to my server. how are you proposing that JMX would get ahold of
that feature? The feature doesn't necessarily stick around at the
Server/Client level at the moment.

If the user wanted to expose a feature via JMX, they could register their feature along with
some name with the Bus, Server, etc. InterceptorProvidor. A JMX user could then get a list
of all features associated with an InterceptorProvidor and select from that list the feature
they would like to manage.

- Dan
Dan Diephouse
Envoi Solutions |

View raw message