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 <[email protected]> > >> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
