Proposal replace auto adding of Feature OSGi service by something more selective and reliable

[Christian Schneider <ch...@die-schneider.net>]

In OSGi we support automatic adding of Features to all services if they 
are published as an OSGi service.

This has some serious drawbacks:

1. Adding all features to all service is too coarse grained for most cases
2. If the bundle containing the feature is started after the service 
bundle then the feature is not added
3. As all features are auto added it is not possible to publish a 
feature as a service that is intended to be added manually (as a service 
reference)

As an example let's take the JAASAuthenticationFeature I added. I played 
around with publishing it as a service to secure all web services.
The problem here was that it would then be difficult to have some 
services unsecured or to have different auth configs for different 
services (e.g. JAAS context name).
Additionally problem 2 also occured in my tests. So it could happen that 
some services that started early would be unsecured which is totally 
unacceptable in a production environment.

Instead of auto adding the features I propose the following:
Each feature should be given a name or ID. This is easy as features 
already provide this. We could then specify that features should be 
published with an OSGi service property cxf.feature.id=<feature id>.
So we would have a way to refer to a feature by name. We could also 
support a property auto-add=true which would make cxf add the feature by 
default to be kind of compatible to the existing mechanism.

Now with the named features we could do two things:
We could have a server level config for cxf where the user could specify 
feature names that should be added to all services like:
features=authentication,authorization

The nice thing about the named features would be that cxf could wait for 
them. So problem 2 can not happen. If we require authentication in the 
server level config then no service will start until the feature is 
present. It could work similar to namespaces in blueprint where a 
blueprint bundle would go into grace period and fail after some 
specified time if dependencies do not appear.

Then as a more fine grained level we could reference features by name in 
the cxf bus or endpoint configs. Like we do with features now. Like that
<cxf:bus>
<requiredFeature>authentication</requiredFeature>
<requiredFeature>authorization</requiredFeature>
</cxf:bus>

This would in the same way as the global config wait for the feature to 
be present until the bundle would start the cxf bus or endpoint. 
Honestly we could already support this today in a bit more verbose way 
by using a blueprint refrence to the feature service with a filter on 
the feature name and by adding the bean from the reference to the 
features. So I am not sure the named reference would be more than 
syntactic sugar.

To summarize .. I think the current mechanism is not really good for 
many cases and the named features would cover the simple cases I named 
much better. For anything more refined we could then use the advanced 
policy management / filtering that Aki proposed some time ago.

So WDYT?

Christian

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com