Hi Alasdair, just a stray thought.
If a reference is kind of optional as in the example below (where a null value is just ignored). Could we maybe also have a version that injects a dummy proxy that if backed by a service forwards the call and otherwise ignores it. Just like the if block would do but without having to write the code :) Regards, Valentin On 8 Aug 2011, at 11:15, Graham Charters wrote: > 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] >>
