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



Mime
View raw message