cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject Re: filtering of features at automatic features loading over osgi service
Date Tue, 19 Mar 2013 14:46:05 GMT
Okay. I see what you mean. It is a bit different but more related than
I initially thought :-)

This "intent" approach is useful when your scenario app knows which
features to use or at least knows which features it intends to use and
tries to find them in osgi services.

The use case that I had in mind was to influence the behavior of some
scenarios from outside, something like instrumentation. And for this
mechanism, I was thinking of providing an option at the service-side
to restrict its applicability to some specific scenarios-apps and also
at the scenario-app-side to exclude the engagement of listeners or
features from some specific services.

I though this use case is somewhat complementary to the "intent" use
case but I am not really sure. I was thinking of introducing a pair of
regex properties to control the behavior of such external
features/listener engagement (which I added in CXF-4900). But I wonder
if it could be better replaced with the intent-based approach of some
forms (e.g. allowing some pseudo intentions like "no-intention" to
mean excluding everything and "any-intention" for including
everything, other concrete intentions to choose specifically)? Not
sure if it's simpler to separate them or unify them.

regards, aki

2013/3/18 Christian Schneider <>:
> 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 property.
> 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.
> Christian
> 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