Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: celix-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4FEABA19.30400@hupie.com>
Date: Wed, 27 Jun 2012 09:45:29 +0200
From: Ferry Huberts <mailings@hupie.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: celix-dev@incubator.apache.org
CC: Alexander Broekhuis <a.broekhuis@gmail.com>
Subject: Re: Celix and Declarative Services
References: 
 <CA+T-u8fFN-2c2V8pbBKY3ir=mYrgkqmHNXha87-FYbeWY=LVtQ@mail.gmail.com>
 <4FE9B241.8060304@hupie.com>
 <CAPhv5g9yVoOsi7JTdgxJ3ph06sW3DBQ5Cz2i-ipyxtcr1q3Hbg@mail.gmail.com>
 <CA+T-u8dQpoHHbb7_4tLy-Hm4jp0Wt3y02RNb0Pt2Qnk5EN4hTw@mail.gmail.com>
 <CA+T-u8ecJk81CORPQfwuW3f0gbEK75bQf2QJgsDfGBnxKdGc4A@mail.gmail.com>
In-Reply-To: 
 <CA+T-u8ecJk81CORPQfwuW3f0gbEK75bQf2QJgsDfGBnxKdGc4A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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