Hi, On 09.11.2011, at 12:08, Bengt Rodehav wrote:
> 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? If you really want to be check the configuration after every reconfiguration, then you should use setter method or the updated callback. > > I have been thinking about adding "synchronize" to my @Validate callback. > Would this be a solution? Would you recommend or argue against it? It won't be enough, you should also synchronize the setter method of your property. In that case, you can be sure that the reconfiguration won't be applied during the @Validate method execution. Regards, Clement > > /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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
