RE: Managing Features via JMX

["Soltysik, Seumas" <Se...@iona.com>]

Hi Dan,
Answers inline.

-----Original Message-----
From: Dan Diephouse [mailto:dan@envoisolutions.com]
Sent: Monday, April 30, 2007 4:43 PM
To: cxf-dev@incubator.apache.org
Subject: Re: Managing Features via JMX


Hi Seumas,


On 4/30/07, Soltysik, Seumas <Se...@iona.com> 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.

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

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

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

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.

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

- Dan
-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog