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 <[email protected]> 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 <[email protected]> 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 > > [email protected] > > > -- Alasdair Nottingham [email protected]
