incubator-celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <>
Subject Re: Celix and Declarative Services
Date Wed, 27 Jun 2012 07:37:27 GMT
I've thought about this a little more, and I'll try to explain what I have
in mind.

> A Service Component Runtime (SCR) needs to have access to functions in
> > another module for activating/deactivating the component. Because
> > Apache Celix has no module layer (yet), the only way to provide this
> > is by creating and registering a service. (Or am I missing
> > something?).
> I want to use dynamic loading for this. Already did some testing and this
> works.
Looking at this, the module layer isn't involved at all. In Java OSGi the
module layer is used to extend the classpath of bundles. This is done using
the bundle's own private/exported packages and all imported packages.

For DS, it is not possible to use the module layer for 2 reasons:
1) Components are typically (and probably should be) placed in the private
package, and as such are not available to other bundles via the module layer
2) If component are exported, the DS bundle needs an import for all these
bundle (a dynamic-import: * would probably work.. but (1) makes this a
needless point anyway)

What actually is done in DS, is some usage of reflection to instantiate a
class based on the information in the component.xml. This simply bypasses
the module layer.
One could as well say that the DS implementation takes over the job (from
the framework) of executing the activator. Of course it does some more
things, like dependency injection.

For Celix an (maybe not complete) alternative for reflection is dynamic
loading. The framework uses this to invoke the activator. This can be done
since the names of the activator functions are known.
Using dynamic loading on other places is still possible though (I don't
think Celix should put any restrictions on the language/libraries, although
some best practices are important! Ie in Java OSGi it is still possible to
mess with the classloader, but doing so is most of the times a (really) bad
Since for a DS component, metadata is stored in the component.xml, the DS
implementation knows some entry points of the component library. Combining
these two, usage of dynamic loading and the component metadata, makes it
possible for DS to create/update the component and inject its dependencies.
The fact that there is no module layer/classpath even makes this a little
bit simpler, in Java the DS has to create the component on the bundle's own
classloader, for Celix it is simply an invocation of a function pointer
created using dlopen and dlsym.
This also fits the analogy I made earlier, for Celix DS again takes over
the job of the framework and creates the component etc.

> > So a declarative service service would be needed to make
> > this work and I think thats not the way to go.
> >
> > I agree with Alexander that a simple solution would be to add this to
> > the framework. In that case the framework SCR has access to the shared
> > libraries and can use dynamic object loading with the names (for
> > activate/deactivate/etc) provided in the DS XML. Although not a nice
> > as a separated SRC bundle, IMO this is -for now - the best solution.
> I think a separate bundle can work for this..
I never meant to add something to the framework, I guess my wording in a
previous email was a little awkward..

As stated above, I do think a separate bundle is doable, without strange
hacks/workaround needed in either the DS implementation or the framework.

I hope this makes sense, and feel free to shoot if you see any gaps/issues!

Met vriendelijke groet,

Alexander Broekhuis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message