Hi Christian,
Christian Schneider wrote > > The startup of dependency injection frameworks like iPojo or blueprint > happens after the bundle start. So this is really asynchronous. The > question is why do you need to know when the component is up? > I'll try to give an overview of what I'm working on. I am currently working on a centralized adaptation mechanism. This centralized mechanism is part of a bigger project that uses planning as a technique to achieve a self-adaptive behavior. In other words, I'm trying to make a foundation to build adaptive applications, that is, an application that can change itself in response of environment changes. And I'm doing it in the architectural level. At this level, the adaptation comes to be a architectural reconfiguration, that is, change some components and, with this, change the behavior of the application. After some research, I found OSGi, which gives a good foundation to build adaptive applications. Moreover, I found iPOJO, that makes the reconfiguration easier by taking care of the bindings and everything. My centralized mechanism receives an adaptation plan that needs to be executed and do not know in advance which components the application will have because it needs to be generic. The adaptation plan is a series of commands with the objective of rearranging the application components. These commands are meant to activate and deactivate components. I am translating it to start and stop bundle commands. This all happens when the application is running and the objective is to preserve the responsive state of the application as much as I can. And, to avoid putting the application in a inconsistent state, I have to execute the commands in a specific order. So, summing everything up, I need to execute some start and stop commands in a specific order and as quick as I can. This is why I need to know when the component is up as soon as possible, for me to be able to fire the next command. Christian Schneider wrote > > Do you want to use it as soon as it is up? If yes then simply reference > a service and make the reference mandatory. You can also use a > ServiceTracker and react on the service coming up. > If I understood what you said I cannot create a mandatory reference to the service, because my mechanism is meant to be generic. I would have to have a reference to all possible services, right? I also thought about using some listener like ServiceTracker, but when thinking of it, I ended with a doubt: The ServiceTracker is an OSGi thing. As far as I know, as iPOJO is built over OSGi, I thought I would need some listener that considers the iPOJO events not the OSGi events. I thought I needed to listen to instance activation events, not service availability events (as far as I know, correct me if I am wrong, they are not the same). The next command in my list (suppose a stop command) should be executed only when the current start command finished to put the instance in a active state, meaning all its iPOJO handlers are valid and the instance is ready to be bound to some other instance when needed. Can I be notified by the ServiceTracker at this specific moment? Do these iPOJO instance validation steps happen after the end od the service initialization process by OSGi, meaning that the ServiceTracker will notify me a little bit earlier than the iPOJO instance is really valid? Or these steps happens during the service initialization, in which case the ServiceTracker will notify me always after every iPOJO things are done? I hope I made myself clear... It is a little bit difficult for me to explain these internal iPOJO/OSGi behavior because I am in the process of learning it yet :-) Please correct me if I am wrong here. Thanks in advance and sorry for the big message. Fabio -- View this message in context: http://apache-felix.18485.n6.nabble.com/How-is-the-most-efficient-way-to-know-when-a-bundle-is-started-tp4997996p4998037.html Sent from the Apache Felix - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
