Dynamically defining which bean to autowire in Spring (using qualifiers)

Question

I have a Java EE + Spring app that favors annotations over XML configuration. The beans always have prototype scope.

I now have in my app business rules that depend

Answer 1

Create your own annotation that is used to decorate instance variables or setter methods, then a post-processor that processes the annotation and injects a generic proxy which resolves the correct implementation at runtime and delegates the call to it.

@Component
public class TransactionService {
  @LocalizedResource
  private TransactionRules rules;
  //..
}

@Retention(RUNTIME)
@Target({FIELD, METHOD})
public @interface LocalizedResource {}

Here is the algorithm for the postProcessBeforeInitialization(bean, beanName) method in your bean post-processor :

1. Introspect the bean class in order to find instance variables or setter methods which are annotated with @LocalizedResource. Store the result in a cache (just a map) indexed by the class name. You can use Spring's InjectionMetadata for this purpose. You can look for examples on how it works by searching references to this classe in spring code.
2. If such a field or method exists for the bean, create a proxy using the InvocationHandler described below, passing it the current BeanFactory (the bean post-processor has to be ApplicationContextAware). Inject that proxy in the instance variable, or invoke the setter method with the proxy instance.

Here is the InvocationHandler for the proxy that will be used to create localized resources.

public class LocalizedResourceResolver implements InvocationHandler {
  private final BeanFactory bf;
  public LocalizedResourceResolver(BeanFactory bf) {
    this.bf = bf;
  }
  public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    String locale = lookupCurrentLocale();
    Object target = lookupTarget(locale);
    return method.invoke(target, args);
  }

  private String lookupCurrentLocale() {
    // here comes your stuff to look up the current locale
    // probably set in a thread-local variable
  }

  private Object lookupTarget(String locale) {
    // use the locale to match a qualifier attached to a bean that you lookup using the BeanFactory.
    // That bean is the target
  }
}

You may need to make some more controls over the bean type, or add the requested bean type in the InvocationHandler.

The next thing is to autodetect implementations of a given interface, which are local-dependant, and register them with the qualifier corresponding to the locale. You can implement a BeanDefinitionRegistryPostProcessor or BeanFactoryPostProcessor for that purpose, in order to add new BeanDefinitions to the registry, with proper qualifier, one for each implementation of locale-aware interfaces. You can guess the locale of an implementation by following naming conventions : if a locale-aware interface is called TransactionRules, then implementations may be named TransactionRules_ISOCODE in the same package.

If you cannot afford such a naming convention, you will need to have some sort of classpath scanning + a way to guess the locale of a given implementation (maybe an annotation on the implementation classes). Classpath scanning is possible but quite complex and slow, so try to avoid it.

Here's a summary of what happens:

1. When the application starts up, implementations of TransactionRules will be discovered and bean definitions will be created for each of them, with a qualifier corresponding to the locale of each implementation. The bean name for these beans is not relevant as lookup is performed based on type and qualifier.
2. During execution, set the current locale in a thread-local variable
3. Lookup the bean you need (eg. TransactionService). The post-processor will inject a proxy for each @LocalizedResource instance fields or setter method.
4. When invoking a method on TransactionService that ends up into some TransactionRules' method, the invocation handler bound to the proxy switches to the correct implementation based on the value stored in the thread-local variable, then delegates the call to that implementation.

Not really trivial, but it works. This is actually how @PersistenceContext is processed by Spring, except for implementations lookup, which is an additional feature of your use case.

Answer 2

You could provide a Configuration class that will return the correct bean based on the ThreadLocal value. This assumes you are using Spring 3. I did a little test to make sure that the provider method was called on each request. Here's what I did.

@Configuration
public class ApplicationConfiguration
{
    private static int counter = 0;

    @Bean( name="joel" )
    @Scope( value="request", proxyMode=ScopedProxyMode.TARGET_CLASS)
    List<String> getJoel()
    {
        return Arrays.asList( new String[] { "Joel " + counter++ } );
    }
}

And referenced the value in my Controller as follows.

@Resource( name="joel" )
private List<String> joel;

in your implementation of the provider you could check the ThreadLocal for the locale and return the correct TransactionRules object or something like that. The ScopedProxy stuff is because I was injecting into a Controller, which is Singleton scoped whereas the value is request scoped.