On 13/02/15 16:52, Matthias Jeschke wrote: > Hi Johan, > > some thoughts to one of your questions. > > On Fri, Feb 13, 2015 at 4:18 PM, Johan Ström <jo...@stromnet.se> wrote: > >> c) Concerning the component instance lifecycle, more specifically >> the call order of Validate/Invalidate/Updated. >> On startup, it seems Updated is called, then Validate, then Updated >> again (but not in all cases? Think I saw other order once..). >> I see two approaches: >> >> 1) Ignore first Updated if validate has not yet been called. Start my >> stuff in Validate. Reconfigure my stuff in Updated. Downside is that i >> reconfigure it once directly after startup, which I'd like to avoid. >> 2) Ignore Updated unless Validate has been called. In Validate, just >> mark "valid". In following Updated, reconfigure/startup as necessary. >> >> Version 2 is what I'll go for I guess, but I wonder, is there any way to >> detect if my component is valid or invalid, besides implementing >> Validate/Invalidate which would just update a boolean? >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> > I think there are two cases how to use validate / update: > > 1) You can update your component while running (e.g. you have thread > running some loop and you can update some properties used inside the loop > so that during the next iteration the new properties are applied). Then you > would configure your component (update) and then start everything in > validate. > 2) You cannot update your component while running (e.g. you have to stop > some process before making modifications and then start it again). Here you > would do the configuration + startup during update. > > However, I would split 2) maybe further. @Updated signals that the update > is complete, so I would use @Property annotations for fields or updateX() > methods (these are invoked / updated first) and then do everything that > starts the relevant process in @Updated. > > Also, please have a look at the live cycle controller, a simple annotated > boolean with which you can impact the live cycle, e.g., signal during an > update that some configuration is wrong so the component is invalidated > after being updated. > > I'm not sure if your 2) is the way to go, as updated should be called > before validate. And I'm not sure if calling updated again after validate > (without actually updating anything) is a "normal" behavior. Updated should > only be called if a configuration has changed, e.g. a new service is > created by a managed service factory or a configuration of a managed > service changed.
In my previous Declarative services-based projects, I've used their update method to either affect my running program (i.e. other threads), or if not possible, just call deactivate() and activate() to simulate a restart. The later would, in DS, be identical to not have a update handler at all, if i remember correct (default on config change was to restart the service).. My version 2 seems indeed messy, but if Update is getting called after initial Validate, I need something like that to avoid restarting everything. This is what I notice on my current test component: Updated called with full configuration. At this stage the properties has been set. Validate called. Updated called again with full configuration, properties still set of course. Then on any change to the config file, Updated is called again. Finally Invalidate is called when config is removed or bundle is stopped. The extra update is indeed confusing and makes things trickier, if it is not supposed to I'd like to find out why it does. I'm running on Karaf 3.0.3 if that makes any difference. > > But I'm also interested in the answers to the other questions you've made, > as I'm still learning iPojo / OSGI as well. Glad to hear I'm not the only one with similar goals :) Johan > > Regards > > Matthias > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
