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