Spring IoC 如何在一个最小的例子中实际工作？

Question

A vast majority of tutorials deal with the degenerate case that there is only exactly one Implementation for the interface to be injected. However, I am at a loss and so far have not found any lead on how to build an application whereof several specialised parts provide several different implementations of common interfaces to be injected into common parts (aka Strategy Pattern, aka Inversion of Control).

In my real-life situation I have a Tomcat server with one application deployed thereon, wherein several parts provide different interfaces to the outside world. In this application, defining a @Bean for a common interface in one specialised @Configuration always results in other specialised parts receiving the same @Bean even though their (only seemingly?) independent @Configuration s define a different @Bean .

For a minimal example, I have attempted to write a Spring-boot application which exhibits the same behaviour and has the same general architecture:

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.CommandLineRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.SpringBootConfiguration;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Import;

@FunctionalInterface
interface Service { boolean test(); }

class CommonProcess {
  @Autowired
  Service service;

  public boolean test() { return this.service.test(); }
}

@Configuration
class BaseConfig {
  @Bean
  CommonProcess commonProcess() { return new CommonProcess(); }
}

@Configuration
class ConfigA {
  @Bean
  CommandLineRunner processA() {
    return new CommandLineRunner() {
      @Autowired
      private CommonProcess process;

      @Override
      public void run(String... args) throws Exception {
        System.out.println(this.process.test());
      }
    };
  }

  @Bean
  Service service() { return () -> false; }
}

@Configuration
class ConfigB {
  @Bean
  CommandLineRunner processB() {
    return new CommandLineRunner() {
      @Autowired
      private CommonProcess process;

      @Override
      public void run(String... args) throws Exception {
        System.out.println(this.process.test());
      }
    };
  }

  @Bean
  Service service() { return () -> true; }
}

@SpringBootConfiguration
@Import(value = { BaseConfig.class, ConfigA.class, ConfigB.class })
class App {
  public static void main(String[] args) {
    System.exit(SpringApplication.exit(SpringApplication.run(App.class, args)));
  }
}

The intent behind this code is as follows:

• Both ConfigA and ConfigB import BaseConfig, because their processes use the same CommonProcess .
• Both ConfigA and ConfigB define their specific, specialised implementation of Service to provide a common value from different sources
  (eg one from XML and one from JSON).
• The class App here is a stand-in for the Servlet I would deploy on a Tomcat server. Obviously, App has to know (provide) all the interfaces the Server should provide, so App has to @Import both ConfigA and ConfigB .
  It is my understanding, that such a "collection point" for "leaf nodes" of an application's abstraction layers needs to exist, in order to expose them all to the world
  (in this example by simply running them, in a Tomcat server by registering their Spring Controllers).

Now, the following behaviours can be observed:

1. Starting the App as is will print false false or true true but never the expected false true or true false ;
2. removing the @Import from App will predictably result in the App not running anything.

Whereas the expected behaviour would be:

1. where CommonProcess is called from ConfigA it uses the service of ConfigA
2. where CommonProcess is called from ConfigB it uses the service of ConfigB

Question: What is the canonical way to produce the expected behaviour?
(annotation-based solution preferred)

---

For reference a working example in plain Java:

import java.util.Arrays;
import java.util.List;

@FunctionalInterface
interface Service { boolean test(); }

class CommonProcess {
  public static final CommonProcess INSTANCE = new CommonProcess();

  public boolean test(Service service) { return service.test(); }
}

class ProcessA implements Runnable {
  // specific project knows generic project -> no need to inject
  private static final CommonProcess commonProcess = CommonProcess.INSTANCE;
  private static final Service service = () -> false;

  public void run() {
    // generic project does not know specific project -> specifics are injected
    System.out.println(this.commonProcess.test(this.service));
  }
}

class ProcessB implements Runnable {
  // specific project knows generic project -> no need to inject
  private static final CommonProcess commonProcess = CommonProcess.INSTANCE;
  private static final Service service = () -> true;

  public void run() {
    // generic project does not know specific project -> specifics are injected
    System.out.println(this.commonProcess.test(this.service));
  }
}

class PlainApp {
  private static final List<Runnable> processes = Arrays.asList(new ProcessA(), new ProcessB());

  public static void main(String[] args) {
    for (Runnable process : processes)
      process.run();
  }
}

Here the output is indeed as expected false true .

Answer 1

You're overthinking Spring IoC and confusing @Configuration with ApplicationContext (the actual IoC container).

@Configuration is processed in scope of an already existing container. And the docs once stated:

@Import represents JavaConfig's equivalent of XML configuration's <import/> element. One configuration class can import any number of other configuration classes, and their bean definitions will be processed as if locally defined.

That is, all imported and discovered @Configurations get loaded into the same container.

After that all singleton beans are created. Then they are wired together.

Within a container you can have multiple beans of the same type but not with the same name . In a JavaConfig, a bean name is derived from either the factory method name or the class name. In case of Service there's just one name, service , and hence just one bean of type Service . If you look closely you'll see a startup message along the lines " Overriding bean definition for bean 'service' with a different definition: replacing [factoryBeanName=ConfigA; factoryMethodName=service; defined in ConfigA] with [factoryBeanName=ConfigB; factoryMethodName=service; defined in ConfigB] "

The one and only service is then wired in everywhere it's needed (in commonProcess , configA and configB ).

In your specific case you can solve it by passing Service to CommonProcess.test() like in your plain Java version, and giving a unique name to each Service instance (eg serviceA and serviceB ):

@FunctionalInterface
interface Service {
  boolean test();
}

class CommonProcess {
  public boolean test(Service service) {
    return service.test();
  }
}

@Configuration
class BaseConfig {
  @Bean
  CommonProcess commonProcess() {
    return new CommonProcess();
  }
}

@Configuration
class ConfigA {
  @Bean
  CommandLineRunner processA(@Named("serviceA") Service service) {
    return new CommandLineRunner() {
      @Autowired
      private CommonProcess process;

      @Override
      public void run(String... args) throws Exception {
        System.out.println(this.process.test(service));
      }
    };
  }

  @Bean
  Service serviceA() {
    return () -> false;
  }
}

@Configuration
class ConfigB {
  @Bean
  CommandLineRunner processB(@Named("serviceB") Service service) {
    return new CommandLineRunner() {
      @Autowired
      private CommonProcess process;

      @Override
      public void run(String... args) throws Exception {
        System.out.println(this.process.test(service));
      }
      @Bean
      Service serviceB() {
        return () -> true;
      }
    };
  }

  @Autowired
  ApplicationContext applicationContext;

  @PostConstruct
  public void printBeans() {
    System.out.println(Arrays.asList(applicationContext.getBeanDefinitionNames()));
  }

  @Bean
  Service serviceB() {
    return () -> true;
  }
}

@SpringBootConfiguration
@Import(value = { BaseConfig.class, ConfigA.class, ConfigB.class })
class App {
  public static void main(String[] args) {
    SpringApplication.run(App.class, args);
  }
}

I would also suggest looking into bean scopes , especially the factory scope.

And finally, Spring Boot supports a hierarchy of ApplicationContext's , which essentially allows you to create sub-applications within one executable. This way ConfigA and ConfigB can each have it's own Service instance named service . This functionality is rarely used.

@SpringBootConfiguration
@Import(value = { BaseConfig.class })
class App {
  public static void main(String[] args) {
    SpringApplicationBuilder app = new SpringApplicationBuilder(App.class);
    app.child(ConfigA.class).run(args);
    app.child(ConfigB.class).run(args);
  }
}