Thanks for you reply Clement although I'm not sure I understand it entirely.
I use ManagedServiceFactories as well when I want to instantiate an arbitrary number of iPOJO instances. When I require exactly one instance then I use a ManagedService. Although I think I understand why you recommend using a ManagedServiceFactory to solve the problem (I guess it forces only one thread to call my callbacks instead of two threads), it doesn't seem like a scenario where ManagedServiceFactories should be used. Isn't it some kind of deficiency if my configuration is updated in the midst of my @Validate callback? How can I ever be sure of having a consistent configuration? I have been thinking about adding "synchronize" to my @Validate callback. Would this be a solution? Would you recommend or argue against it? /Bengt 2011/11/8 Clement Escoffier <[email protected]> > 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] > >
