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
