T- the component interface
public abstract class AbstractSwitchingInvocationAdaptor<T> extends AbstractComponentAdaptor<T>
ComponentAdapterthat returns a JDK dynamic proxy that in turn switches between two possible implementations (an "enabled" one and a "disabled" one), based on the return value of a given
InvocationSwitcher. TODO Replace this class with a
|Modifier||Constructor and Description|
|Modifier and Type||Method and Description|
Returns the interface class that this adaptor was registered with.
Returns the invocation switcher that will choose between the "enabled" and "disabled" implementations.
accept, findAdapterOfType, getComponentInstance, getComponentKey, getDelegate, getDescriptor, verify
protected AbstractSwitchingInvocationAdaptor(Class<T> interfaceClass, Class<? extends T> enabledClass, Class<? extends T> disabledClass)
interfaceClass- the interface implemented by the component
enabledClass- the implementation to use when the invocation switcher returns "enabled"
disabledClass- the implementation to use when the invocation switcher returns "disabled"
WARNING: This should NOT return either concrete implementation class!
When Pico needs to satisfy a dependency but the class it is asked for is not registered, it reacts by asking every component adaptor that is registered what its concrete implementation class is. The thinking is that maybe, just maybe, it can find something registered under a different key that can satisfy this dependency.
This is the method that Pico uses to do that, and what it's trying to figure out is "When I ask you for your component instance, of what class will it be?" Previously, this method returned the specific implementation class that it would delegate to right now, but there are two major problems with doing that:
getComponentInstance(PicoContainer)to yield an object of that class. However, what we actually return is a dynamic proxy for our own registration interface, not either of the concrete implementations. Our own registration interface cannot be the desired one or Pico would have resolved it to us without asking this question in the first place, so this would NEVER work.
StackOverflowErrorinstead of gracefully reporting the unsatisfiable dependency. This makes the problem harder to diagnose and fix, so let's not do that.
The most accurate answer here would be to return the actual dynamic proxy class we will use, but returning the interface we registered under is simpler, still honest, and should be good enough.
public final T getComponentInstance(org.picocontainer.PicoContainer container) throws org.picocontainer.PicoCompositionException
Copyright © 2002-2019 Atlassian. All Rights Reserved.