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 idea.). 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
