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.

Greetings,
Pepijn