Hi Seumas,
On 4/30/07, Soltysik, Seumas <[EMAIL PROTECTED]> 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. 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... 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. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
