lol. Freehand strikes. Naturally the .get() method needs to have code prior to the != null if an external force/trigger can instantiate another D instance. I'm usually dealing with listener threads that replace the contents of currentD out from under me whenever. Cheers!
On Thu, Dec 9, 2010 at 7:36 PM, Brian Lough <[email protected]> wrote: > No offense, IMHO, what you're trying to do just smells bad. There's a > unnecessary coupling of these classes causing these gyrations that I can't > put my finger on. I'm swapping one runtime instance for another easily way > down in dependency chains just by using sub-classes of Provider and .get(). > D is the wonky one, so maybe this will lead somewhere....(typing freehand > so..) > > public class DProvider implements Provider<D> { > > private AtomicReference<D> currentD = new AtomicReference<D>(null); > > @Inject > public DProvider(Whatever dNeeds) { .. } > public D get() { > if (currentD.get() != null) { > return currentD.get(); > } > > D oldD = currentD.get(); > oldD.releaseResources(); > D newD = createDBasedOnWhateverRuntimeCriteria(); > currendD.set(newD); > return newD; > } > > Anyone requiring an instance of D, regardless of position in the dependency > chain, gets DProvider injected. As long as they get their D instance via > injectedDProvider.get() anytime they access a method of D, they're certain > to get whatever runtime instance you've swapped in/out. > > Hope this helps. Took a shot. :-D > > > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
