On 27-06-12 09:37, Alexander Broekhuis wrote:
> 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!
>

good explanation.
thanks

-- 
Ferry Huberts