On 6/18/12 21:46 , fabiolf wrote:
Richard,

On another point in my project I solved a problem using temporal
dependencies because I didn't want my application to be restarted when I
switched an instance inside a composite. But I am curious. Why have you said
that I would want to use temporal dependencies all over the place

Actually, I said you don't want to...

Are there
any side effects of using temporal dependencies? I am asking because I am
considering using it exactly all over the place :)

They are the equivalent of having no dependencies and just doing on-demand lookups of services. So, you never really know if a service will be available when you go to use it. It may be there, it may block you for a long period of time, or it may throw an exception.

To some degree, this is similar to the default behavior of Blueprint (it calls this damping; it is not 100% equivalent to temporal dependencies, but pretty close). It is like trying to pretend service dynamism doesn't exist.

In systems where you don't expect to have any dynamism except for the occasional update, this may be ok. However, it is not ok in a truly dynamic system.

-> richard


Thanks,
Fabio


Richard S. Hall wrote
Granted, I haven't been completely paying attention so this may not be
relevant, but...

Perhaps you could use a temporal dependency. In that case, your
application thread would get blocked while the service provider was
being switched instead of invalidated.

You don't want to use temporal dependencies all over the place, but if
used strategically they can be useful.

-> richard



--
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-tp4997996p4998170.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]




---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to