Hi Fabio,
so let me try to explain in my words what you try to do.
Parts of the behaviour of your application should be able to change at
runtime. I guess you are implementing this by defining a service and
referencing it. So what really happens depends on the service
implementation.
If you have only one implementation at a time for a service then a
mandatory service is the way to go. I have an example for this at:
http://www.liquid-reality.de/display/liquid/2011/02/15/Karaf+Tutorial+Part+1+-+Installation+and+First+application
The example uses blueprint not iPojo but the idea should be similar. It
has a model, persistence and UI. If you just install the model and UI
the UI will not start as it depends on the peristence service. As soon
as you install and start the persistence bundle it will come up. This
allows to exchange the persistence at runtime. Uninstall the old bundle
install the new one and the UI will restart and use the new persistence.
There is no need to wait for bundle start / stop as the mandatory
service reference already implements the needed behaviour.
If you want to use more than one service then you can also refer to a
service list in blueprint. This list will then always reflect all the
service impls for an interface. This way you can implement event
listeners easily.
So to sum it up:
Simply use service references and let blueprint (I hope iPojo can do the
same) wire your application. When you have to adapt to a change simply
exchange the impl bundles and the application will set itself up with
the new impls. There should be no need to wait for bundle start / stop.
One really nice thing is that by implementing your application using
services at the right points you can already prepare for your adaptive
scenario without putting a lot of effort into it in the start.
Christian
Am 13.06.2012 15:12, schrieb fabiolf:
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]
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
