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?
/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] > >
