felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clement Escoffier <clement.escoff...@gmail.com>
Subject Re: ipojo and default values
Date Tue, 08 Nov 2011 13:03:42 GMT
Hi,

Sorry for this pretty late reply…

On 28.10.2011, at 11:05, Bengt Rodehav wrote:

> Hello Clement,
> 
> I have used the @Updated annotation (haven't tried the @Property on a method
> though). The problem is that the @Updated method is called while I'm in the
> midst of executing the @Validate method (which uses the property that is
> being changed). I guess this must be done on separate threads (haven't
> checked).

Yes, the @Updated method is with the config admin thread, while @Validate is called by the
iPOJO processing thread.

> 
> Having updates of the configuration taking place while executing an iPOJO
> callback (like the @Validated method) doesn't really make sense to me. For
> me, it means that I use the old value (8093) in my @Validate method instead
> of the new value (9991). I know that OSGi is a very dynamic environment and
> the configuration can change at any time. Therefore I do reinitialize my
> iPOJO when certain values change. The problem is that I'm only informed once
> about configuration changes (@Updated) and if that happens when I'm in the
> @Validated method I miss the opportunity.
> 
> I'm probably approaching this the wrong way but do you know what best
> practice is for the following:
> 
> - Having a configuration property with a default value
> - Using the configuration property to initialize the iPOJO
> - Doing the initialization when the iPOJO becomes valid and re-initializing
> whenever the property changes
> - It must be guaranteed that the re-initialization is never done until the
> first initialization has been completed (in the @Validate method) and I must
> not "miss" any re-initialization.
> 

If you want to be sure you get only one value, you should use a ManagedServiceFactory instead
of a ManagedService. Then you configure the instance with the new value (if not set will use
the default value). By using a ManagedServiceFactory configuration, iPOJO will creates the
instance (so no need of @Instance) with the right configuration. 

Regards,

Clement


> /Bengt
> 
> 
> 2011/10/28 Clement Escoffier <clement.escoffier@gmail.com>
> 
>> Hi,
>> 
>> 
>> On 27.10.2011, at 23:35, Bengt Rodehav wrote:
>> 
>>> I'm using iPOJO and have problems with default property values. Consider
>> the
>>> following:
>>> 
>>> *  @Property(name = "url", mandatory = true, value = "
>>> http://localhost:8093/service")*
>>> *  private String mUrl;*
>>> 
>>> If I use config admin (with fileinstall) to provide an override to the
>> "url"
>>> property (changing the port from 8093 to 9991), then the following
>> happens:
>>> 
>>> 1. My @Update method is called. The port is 8093.
>>> 2. My @Validate method is called. It does some initialization that can
>> take
>>> a second or two. On entering the @Validate method the port is 8093.
>>> 3. My @Update method is called again. The port is now 9991 which means
>> that
>>> this is the value from config admin. Note that my @Validate method is not
>>> done at this point.
>>> 4. My @Validate method returns. At this point the port is 9991. However,
>> the
>>> initialization code in the @Validate method used the port 8093 not 9991
>> that
>>> I wanted to use.
>>> 
>>> I expected the port 9991 to be used since I had overridden the default
>> port
>>> (8093). I'm not sure why this is happening. How can I guarantee that the
>>> overridden port is used instead of the default port?
>>> 
>>> Note that since the update to port 9991 takes place while I'm in my
>>> @Validate method I missed the update and I won't be informed about it
>> again.
>> 
>> If you want to be notified after a reconfiguration, you can use @Property
>> on a method (called when the value is injected) or use the @Updated called
>> when a reconfiguration occurred (and when the reconfiguration is completed).
>> 
>> @Validate is called only once (or after an invalidation).
>> 
>> Regards,
>> 
>> Clement
>> 
>>> 
>>> /Bengt
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
>> 


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


Mime
View raw message