Thanks Clement, /Bengt
2011/11/11 Clement Escoffier <[email protected]> > > On 11.11.2011, at 09:23, Bengt Rodehav wrote: > > > Clement, > > > > I use an @Updated callback today. In the callback I check if certain > > important properties have changed and if so, I trigger a > re-initialization. > > Would this work if I make both m @Validate callback and my @Updated > > callback synchronized? Or do I have to introduce setter methods as well > on > > those properties and make them synchronized? > > Yes it will work. Then you're sure that callback won't be executed at the > same time. > > Regards, > > Clement > > > > > /Bengt > > > > 2011/11/10 Clement Escoffier <[email protected]> > > > >> 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] > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
