celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferry Huberts <maili...@hupie.com>
Subject Re: Celix and Declarative Services
Date Tue, 26 Jun 2012 18:59:00 GMT

On 26-06-12 20:51, Pepijn Noltes wrote:
> Hi All,
> On Tue, Jun 26, 2012 at 2:59 PM, Ferry Huberts <mailings@hupie.com> wrote:
>> On 26-06-12 14:28, Alexander Broekhuis wrote:
>>> Hi all,
>>> After Ferry's question I've been looking a little at the OSGi Declarative
>>> Services spec, and I think most of it can be realized using the current
>>> Celix implementation.
>> that would be absolutely awesome!
> I agree this would be a really nice feature.
>>> One of the problems I've seen so far is related to service registration.
>>> Using Java a service is an interface, and through reflection and the
>>> implementation of the component, this interface can be registered as a
>>> service by the DS implementation.
>>> In Celix a service is a struct with function pointers, which has to be
>>> instantiated by the user. It is not possible to do this dynamically, the
>>> DS
>>> implementation does not know the functions of the component etc.
>>> A simple solution would be to use an additional function in the component
>>> in which the service struct is created. Downside of this is, that there is
>>> no strict separation of component and framework code....
>> Why not? (maybe I'm missing something)
>> IMHO it's just a method extra on the 'activator' interface (or an extra
>> 'special' interface).
>> Right now you have start/stop/etc there. You'd just be adding something like
>> 'instantiateServiceRegistrationStruct' there, wouldn't you?
> 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?). 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.

that's what I meant as well. I see now that my mail wasn't really clear 
on that ;-)

> Greetings,
> Pepijn

Ferry Huberts

View raw message