aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Do we really need Quiesce support?
Date Thu, 12 Feb 2015 15:20:12 GMT
I just checked the diff of my changes when removing Quiesce. We would be 
able to remove ~20 classes and 1500 lines of code.
So I think it would be worth the time to check if we can achieve the 
same with an alternative solution.

Apart from complexity and code size my big problem with the way Quiesce 
works in aries jpa is that it creates a proxy for the EMF and the EM 
with artificial methods to shut it down.
I think that is not a good idea at all. With the proxied EMF we also 
shut down EMs that other bundles created. This can lead to problems in 
these bundles as they are probably not aware of this.

I think we should rather track the EMs we create ourself (mainly in the 
jpa blueprint code) and close these when the quiesce happens.


On 12.02.2015 11:25, Graham Charters wrote:
> Hi David/Christian,
> Here is what Mark wrote, that didn't make it:
> "Quiesce is about stopping a bundle gracefully prior to its uninstallation,
> which is why we've had no need to implement a 'restart' capability. We
> currently use Apache Aries quiesce within IBM WebSphere Application Server.
> It's used in a scenario where an administrator is replacing some of the
> bundles within a running application. The code has been in use in that
> product for some years now so yes, I'm sorry but we do have a definite need
> for the facility."
> Essentially, we use it to notify containers/extenders of bundles that are
> about to be uninstalled (prior to that actually being done) so they can
> perform house-keeping ahead of uninstallation being kicked off.
> Regards, Graham.

Christian Schneider

Open Source Architect

View raw message