You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Mathieu Civel <ma...@gmail.com> on 2009/05/26 16:48:52 UTC

[iPOJO 1.3.0] reconfiguration update callback

Hi Clément,

I'm using the combo File Install/Config Admin to manage my instances (great
combo :), and it works fine except for one case :

When the config file adds a new property, not mentionned in the <properties
propagation="true" updated="reconfigured"> clause, the new property isn't
given in the Dictionary, but  is well managed by the provides handler.

Is that possible for you to check that or tell me that it's a wanted
behavior ?

Thanks.

Mathieu Civel.

P.S. It seems that BND don't want a lowercase letter for manifest keys
(tryed the ant task only), hence ipojo-log-level didn't work for me until i
changed it to Ipojo-lol-level in the ipojo sources.

Re: [iPOJO 1.3.0] reconfiguration update callback

Posted by Mathieu Civel <ma...@gmail.com>.
Allright, I've just added a jira issue : FELIX-1182

Thanks.



2009/5/27 Clement Escoffier <cl...@gmail.com>

> Hi,
>
> On 26.05.2009, at 16:48, Mathieu Civel wrote:
>
>  Hi Clément,
>>
>> I'm using the combo File Install/Config Admin to manage my instances
>> (great
>> combo :), and it works fine except for one case :
>>
>> When the config file adds a new property, not mentionned in the
>> <properties
>> propagation="true" updated="reconfigured"> clause, the new property isn't
>> given in the Dictionary, but  is well managed by the provides handler.
>>
>>
>> Is that possible for you to check that or tell me that it's a wanted
>> behavior ?
>>
>
> I will  not say that it's a "wanted" behavior. When I implemented the
> updated callback, I wondered if such properties (propagated but not managed
> by the handler itself) had to be injected in the updated callback parameter
> or not. My first conclusion was not (simplicity)... but it makes sometimes
> perfects to inject them. This will allow the object to be notified when new
> service property are added.
>
> Could you open an issue about that? I will fix it ASAP.
>
>
>>
>> Thanks.
>>
>> Mathieu Civel.
>>
>> P.S. It seems that BND don't want a lowercase letter for manifest keys
>> (tryed the ant task only), hence ipojo-log-level didn't work for me until
>> i
>> changed it to Ipojo-lol-level in the ipojo sources.
>>
>
>
> Good catch ! I will modify the property to support also IPOJO-log-level.
>
> Regards,
>
> Clement
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>

Re: [iPOJO 1.3.0] reconfiguration update callback

Posted by Clement Escoffier <cl...@gmail.com>.
Hi,

On 26.05.2009, at 16:48, Mathieu Civel wrote:

> Hi Clément,
>
> I'm using the combo File Install/Config Admin to manage my instances  
> (great
> combo :), and it works fine except for one case :
>
> When the config file adds a new property, not mentionned in the  
> <properties
> propagation="true" updated="reconfigured"> clause, the new property  
> isn't
> given in the Dictionary, but  is well managed by the provides handler.
>
>
> Is that possible for you to check that or tell me that it's a wanted
> behavior ?

I will  not say that it's a "wanted" behavior. When I implemented the  
updated callback, I wondered if such properties (propagated but not  
managed by the handler itself) had to be injected in the updated  
callback parameter or not. My first conclusion was not (simplicity)...  
but it makes sometimes perfects to inject them. This will allow the  
object to be notified when new service property are added.

Could you open an issue about that? I will fix it ASAP.

>
>
> Thanks.
>
> Mathieu Civel.
>
> P.S. It seems that BND don't want a lowercase letter for manifest keys
> (tryed the ant task only), hence ipojo-log-level didn't work for me  
> until i
> changed it to Ipojo-lol-level in the ipojo sources.


Good catch ! I will modify the property to support also IPOJO-log-level.

Regards,

Clement


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org