aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Charters <gchart...@gmail.com>
Subject Re: Blueprint service reference damping
Date Mon, 08 Aug 2011 10:15:15 GMT
Hi Alasdair,

Seems like a pretty neat solution.  I'd assumed you would do something
in the XML, rather than the implementation bean.  FWIW, I've heard
other people wanting to be able to switch off the damping, so having
this option would be very useful.

Regards, Graham.

On 6 August 2011 12:16, Alasdair Nottingham <not@apache.org> wrote:
> If there is no matching service the AtomicReference.get() method will return
> null. This is why the call to s is protected by an s != null check.
>
> On 6 August 2011 11:20, Andreas Pieber <anpieber@gmail.com> wrote:
>
>> Hey Alasdair,
>>
>> I've one question belonging to this proposal:
>>
>> MyService s = injectedReference.get();
>> if (s != null) {
>>   s.call();
>> }
>>
>> What is supposed to happen if the serviceReference is null?
>>
>> Thanks and kind regards,
>> Andreas
>>
>> On Sat, Aug 6, 2011 at 11:49, Alasdair Nottingham <not@apache.org> wrote:
>>
>> > Hi,
>> >
>> > I've been hitting a few problems with blueprint recently due to the way
>> the
>> > blueprint service reference damping works. There are two problems that I
>> > have hit:
>> >
>> >   1. When a service goes away and is not replaced, such as on shutdown,
>> if
>> >   you "accidentally" call a service you get a, by default, 5 minute wait.
>> >   2. As a user of a service proxy you need to cope with a
>> >   ServiceUnavailableException. It is especially an issue with optional
>> > service
>> >   and if you have a dynamic environment.
>> >
>> > The first problem can be overcome by shortening the timeout, but you are
>> > stuck with the second. I also have the proxy involving less code between
>> me
>> > and the service. In addition proxying service classes is harder.
>> >
>> > For a while now I've been thinking of allowing a mode where you can get a
>> > raw service injected instead of damped one. The problem is we are only
>> > supposed to driver the setters once at bean creation, not multiple times.
>> > After some thought I have an approach which I have proved. The approach
>> is
>> > that if the target setter takes an AtomicReference we will inject one of
>> > those and replace the service in the reference behind the scenes. This
>> > means
>> > you would write code like:
>> >
>> > MyService s = injectedReference.get();
>> > if (s != null) {
>> >    s.call();
>> > }
>> >
>> > rather than:
>> >
>> > injectedReference.call();
>> >
>> > it seems to work quite well. It only affects what is injected, binding
>> > listeners still have the same behaviour as before. Since this change
>> > affects
>> > the programming model somewhat I wanted to see what peoples thoughts were
>> > before I committed it.
>> >
>> > Alasdair
>> >
>> > --
>> > Alasdair Nottingham
>> > not@apache.org
>> >
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>

Mime
View raw message