From celix-dev-return-232-apmail-incubator-celix-dev-archive=incubator.apache.org@incubator.apache.org Tue Jun 26 18:59:28 2012 Return-Path: X-Original-To: apmail-incubator-celix-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-celix-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E146CCD1C for ; Tue, 26 Jun 2012 18:59:28 +0000 (UTC) Received: (qmail 79103 invoked by uid 500); 26 Jun 2012 18:59:28 -0000 Delivered-To: apmail-incubator-celix-dev-archive@incubator.apache.org Received: (qmail 79079 invoked by uid 500); 26 Jun 2012 18:59:28 -0000 Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: celix-dev@incubator.apache.org Delivered-To: mailing list celix-dev@incubator.apache.org Received: (qmail 79065 invoked by uid 99); 26 Jun 2012 18:59:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Jun 2012 18:59:28 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [80.101.237.101] (HELO hupie.dyndns.org) (80.101.237.101) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Jun 2012 18:59:23 +0000 Received: from stinkpad.internal.hupie.com (hupie.dyndns.org [80.101.237.101]) by hupie.dyndns.org (Postfix) with ESMTP id 212B9485090; Tue, 26 Jun 2012 20:59:01 +0200 (CEST) Message-ID: <4FEA0674.1000109@hupie.com> Date: Tue, 26 Jun 2012 20:59:00 +0200 From: Ferry Huberts 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: Pepijn Noltes Subject: Re: Celix and Declarative Services References: <4FE9B241.8060304@hupie.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 26-06-12 20:51, Pepijn Noltes wrote: > Hi All, > > On Tue, Jun 26, 2012 at 2:59 PM, Ferry Huberts 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