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
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
