cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: filtering of features at automatic features loading over osgi service
Date Mon, 18 Mar 2013 16:34:36 GMT
That is true, it is a bit different. I think were both aproaches meet is 
that we should be able to control which extensions and features are loaded.
Simply loading everything is too coarse grained. For extensions the 
default of loading every extension may make sense as they are often 
things like transports or data formats.
These are simply available and are activated by settings in the service.

At least for features this is different though. Outside of OSGi features 
are only activated if they are listed in the service endpoint or proxy. 
So simply loading them all in OSGi is not enough.
A simple aproach may be to do it like in dOSGi. There you can list named 
"intents" in an endpoint and include features this way. So a feature 
could be published as an OSGi service and be given a name in an OSGi 
Then you could list the features you want in the properties of an 
endpoint or proxy and so filter the loading.

Even better would be to have a plugable mechansim that decides which 
features to load. My policy manager would then be such an 
implementation. The simple activation by name would be another.

Btw. one big advantage of naming the required features is that you can 
wait for them. I implemented this for intents in the current dosgi 
version. The advantage is that you do not have to start features in a 
lower start level
than the user bundle that needs them.


Am 18.03.2013 10:28, schrieb Aki Yoshida:
> Hi Christian,
> your use case seems like creating some kind of automatic policy
> derivation mechanism based on other properties of the scenario. It's
> an interesting approach that makes some scenarios more flexible as
> they don't need to explicitly use policies but could make the thing
> complex as we don't see policies explicitly?
> But in any case, I think this use case has a different aspect than
> simply controlling/restricting the automatic engagement of the
> published features or lifecycle listeners from somewhere else into the
> bus.
> regards, aki

Christian Schneider

Open Source Architect
Talend Application Integration Division

View raw message