aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Charters <gchart...@gmail.com>
Subject Re: Do we really need Quiesce support?
Date Thu, 12 Feb 2015 09:30:43 GMT
Hi Christian,

Apologies for not responding sooner, Mark Nuttall tried to reply on this
thread, but his email did not make it.  We use Quiesce support in WebSphere
so need this to be left in.  Please do not remove it.  Many thanks.

Graham.

On 12 February 2015 at 08:02, Christian Schneider <chris@die-schneider.net>
wrote:

> I created an issue to track the removal of the quiesce support in aries
> jpa.
> https://issues.apache.org/jira/browse/ARIES-1297
>
> I have prepared a commit and plan to apply the removal on next monday if
> no one opposes.
>
> Christian
>
>
> On 10.02.2015 09:15, Christian Schneider wrote:
>
>> In several places in aries we support the Quiesce API. As far as I
>> understood its purpose is to shut down bundles without actually stopping
>> them. It does not seem to be any standard as the interfaces are in the
>> Aries namespace.
>>
>> The problem with it is that it complicates the code a lot. For example in
>> jpa container we create a proxy for each EntityManager that also supports
>> quiesce methods even though they are
>> not part of the EntityManager interface. The code in other modules is
>> similarly affected.
>>
>> Besides this I do not see anyone using the API. I am also not sure why we
>> need it at all as OSGi already has nice lifecycle methods to stop bundles
>> which should have a similar effect if implemented nicely. One other
>> disadvantge of Quiesce is that you can only shut down a bundle. You can not
>> restart it again.
>>
>> So the question is: Do we really need to support the Quiesce API? The
>> code would be a lot less complex and error prone without it.
>>
>> WDYT?
>>
>> Christian
>>
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message