Return-Path: 
 <felix-dev-return-2117-apmail-incubator-felix-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-felix-dev-archive@www.apache.org
Received: (qmail 29200 invoked from network); 9 Jun 2006 09:21:19 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 9 Jun 2006 09:21:19 -0000
Received: (qmail 99652 invoked by uid 500); 9 Jun 2006 09:21:19 -0000
Delivered-To: apmail-incubator-felix-dev-archive@incubator.apache.org
Received: (qmail 99598 invoked by uid 500); 9 Jun 2006 09:21:18 -0000
Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:felix-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:felix-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:felix-dev@incubator.apache.org>
List-Id: <felix-dev.incubator.apache.org>
Reply-To: felix-dev@incubator.apache.org
Delivered-To: mailing list felix-dev@incubator.apache.org
Received: (qmail 99579 invoked by uid 99); 9 Jun 2006 09:21:18 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Jun 2006 02:21:18 -0700
X-ASF-Spam-Status: No, hits=1.4 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: 129.88.30.1 is neither permitted nor
 denied by domain of clement.escoffier@gmail.com)
Received: from [129.88.30.1] (HELO imag.imag.fr) (129.88.30.1)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Jun 2006 02:21:17 -0700
Received: from [129.88.39.107] (clement.imag.fr [129.88.39.107])
	by imag.imag.fr (8.13.6/8.13.6) with ESMTP id k599KoVM023014
	for <felix-dev@incubator.apache.org>; Fri, 9 Jun 2006 11:20:50 +0200 (CEST)
Message-ID: <44893D63.2020109@gmail.com>
Date: Fri, 09 Jun 2006 11:20:35 +0200
From: Clement Escoffier <clement.escoffier@gmail.com>
Organization: LSR - Imag
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: felix-dev@incubator.apache.org
Subject: Re: iPOJO and Configuration Admin Service
References: <1149804575.6508.18.camel@trout>
In-Reply-To: <1149804575.6508.18.camel@trout>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender IP whitelisted,
 not delayed by milter-greylist-1.6 (imag.imag.fr [129.88.30.1]);
 Fri, 09 Jun 2006 11:20:50 +0200 (CEST)
X-IMAG-MailScanner-Information: Please contact IMAG DMI for more information
X-IMAG-MailScanner: Found to be clean
X-MailScanner-From: clement.escoffier@gmail.com
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Hi,

and thank you for the feedback.

>
> <iPOJO>
> <component 
>
> className="com.verticon.experiment.ipojo.configuration.ConfiguribleEventHandler"   name="com.verticon.experiment.ipojo.configuration" architecture="true">
>   <Provides 
>    interface="org.osgi.service.event.EventHandler">
>    <DynamicProperty 
>         name="event.topics"
> field="topics"
> value="com/verticon/rfid/MOVEMENT"/>
> </Provides>
>   <ConfigurableProperty 
>             field="topics" name="event.topics" />
>     <callback 
>              final="VALID" initial="INVALID" method="starting"/>
>     <callback 
>              final="INVALID" initial="VALID" method="stopping"/>
> </component>
> </iPOJO>
>   
These metadata mean that only the field "topics" is configurable. Then 
all other field's name are rejected. Nevertheless, your field is a 
dynamic property too, so it should propagate your value to the service 
registration. The version that you used does not handle property's name 
but only property's field. I change this to support property name too 
(if no name, I use the property field). So with the new deployed version 
(always 2.6), your metadata should be correct.

> 1. The first issue (problem?) that I see is that the iPOJO container
> (org.apache.felix.ipojo.handlers.configuration.ConfigurationHandler)
> registers, unregisters, and registers a second time as a ManagedService
> with the framework. Note the ConfiguationAdmin
> (org.apache.configuration.impl) implementation uses a separate thread
> for callbacks to invoke the updated method on the service. 
>   
It was a small bugs when the handler start and when the component state 
changes. So I correct it. I test it and it seems to work. (reinstall the 
2.6 version, at the same location).

>
> 2. The second issue I have seen is that the container
> (ConfigurationHandler) is rejecting all configuration properties.
> (Would have expected at least that the event.topics would be accepted
> and propagated as it is specified in the metadata.  Or did I setup the
> metadata wrong?)
>
> Don't think the container can be so picky with the configs. As specified
> in the OSGi Compendium Spec R4 p 70-432 All Configuration Properties
> should be accepted and propagated to the service registration by the
> ManagedService (in this case the iPOJO container). Here is a log output:
>   

The new pushed values are propagated to the service registration if the 
provided services contains a dynamic property with the same field name 
than the configurable property.
My configuration handler does not do anything with all other 
configuration, I changed the log level of the message form SEVERE to 
WARNING. It means that you push a non consistent configuration to the 
component (there is no configurable property with this name).


Clement