I think this is in part because of the service damping in blueprint.
Blueprint will not shut down a service if a service it depends on goes away.
If you have a more reactive framework like DS it would not happen. If
you remove the DataSource then any DS component using it will also go down.
Besides I am not sure how quiesce can solve that? You still have to
quiesce the correct bundle.
Imagine bundle A contains the bean with JPA access and bundle B contains
the CXF service which uses the service from B.
If you quiesce bundle A then bundle B will still provide the CXF service
but does not work anymore (when using blueprint).
It would have the same effect to simple stop bundle A. Maybe I am
missing something but how does the Quiesce API support this better?
Christian
On 12.02.2015 12:06, Guillaume Nodet wrote:
I think I actually do understand the need.
When you want to stop a bunch of bundles, you can choose to stop them in a
random order, or in a smart way.
At the end the result may not be the same.
Let me take an example: a cxf service which accesses a database.
If you choose a random order, you may shut down the database access
(DataSource in osgi for example), before shutting down the cxf service.
The effect will be that you will make inflight requests to fail.
The correct way would be to shut down the cxf service in a clean way, i.e.
do not accept any more incoming requests, and wait for inflight requests to
be finished, then shut down the cxf service, then shutdown the jdbc factory.
This is somewhat what the bluprint extender try to do when you shutdown the
extender itself, but if you bundles encompass multiple different extenders,
they need to cooperate in a smarter way. This could also apply to CXF
services, camel routes, etc...
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
