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.
Christian
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
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
