public abstract class


extends AbstractComponentAdaptor<T>
   ↳ com.atlassian.jira.config.component.AbstractComponentAdaptor<T>
     ↳ com.atlassian.jira.config.component.AbstractSwitchingInvocationAdaptor<T>
Known Direct Subclasses


Inherited Fields
From class com.atlassian.jira.config.component.AbstractComponentAdaptor
Protected Constructors
AbstractSwitchingInvocationAdaptor(Class<T> interfaceClass, Class<? extends T> enabledClass, Class<? extends T> disabledClass)
Public Methods
Class<? extends T> getComponentImplementation()
Returns the interface class that this adaptor was registered with.
T getComponentInstance(PicoContainer container)
Protected Methods
InvocationHandler getHandler(PicoContainer container)
abstract InvocationSwitcher getInvocationSwitcher()
boolean isEnabled()
Inherited Methods
From class com.atlassian.jira.config.component.AbstractComponentAdaptor
From class java.lang.Object
From interface org.picocontainer.ComponentAdapter

Protected Constructors

protected AbstractSwitchingInvocationAdaptor (Class<T> interfaceClass, Class<? extends T> enabledClass, Class<? extends T> disabledClass)

Public Methods

public Class<? extends T> getComponentImplementation ()

Returns the interface class that this adaptor was registered with.

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:

  1. If by some strange coincidence the class we return accidentally does satisfy the missing dependency, then Pico will expect a call to 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.
  2. The act of determining the concrete implementation will probably access other components, most likely application properties and the caching property set that backs them. If they also haven't been resolved yet, then the result is likely to be infinite recursion leading to a StackOverflowError instead 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.

  • the interface class that this adaptor was registered with.

public T getComponentInstance (PicoContainer container)


Protected Methods

protected InvocationHandler getHandler (PicoContainer container)

protected abstract InvocationSwitcher getInvocationSwitcher ()

protected boolean isEnabled ()