Überschreiben Bohnen in Java-basierte spring-Konfiguration Hierarchie

Nehmen wir an wir haben eine Anwendung, die angepasst werden kann für einige Kunden. Die Anwendung ist über Java-basierte spring-Konfiguration (ein.k.ein. Java-config) für dependency injection. Die Anwendung besteht aus Modulen und deren Teilgebiete. Jedes Modul und Submodul hat seine eigene @Configuration Klasse importiert werden, die von übergeordneten Konfiguration mit @Import. Dadurch entsteht die folgende Hierarchie:

                MainConfig
          ----------+----------------   ....
          |                         |
    ModuleAConfig               ModuleBConfig
      |--------------------|
      |                    |
    SubModuleA1Config    SubModuleA2Config

Beispielsweise ModuleAConfig sieht wie folgt aus:

@Configuration
@Import({SubModuleA1Config.class, SubModuleA2Config.class})
public class ModuleAConfig {
    //some module level beans
}

Lassen Sie uns sagen, dass SubModuleA1Config definiert bean someBean Typ SomeBean:

@Configuration
public class SubModuleA1Config {
    @Bean
    public SomeBean someBean() { return new SomeBean(); }
}

Nun möchte ich, um die Anwendung anpassen für Customer1 (C1) - möchte ich C1SomeBean (Erweiterung SomeBean) statt SomeBean als someBean.

Wie kann ich erreichen, das mit mindestens Verdoppelung?

Einer meiner Ideen war die Vorbereitung alternative Hierarchie mit C1Config Erben von MainConfig, C1ModuleAConfig aus ModuleAConfig und C1SubModuleA1Config aus SubModuleA1Config. C1SubModuleA1Config Kraft setzen würden someBean() Methode der Rückkehr C1SomeBean. Leider mit Feder 4.0.6 bekomme ich so etwas wie:

   Overriding bean definition for bean 'someBean': replacing [someBean defined in class C1SubmoduleA1Config] with [someBean defined in class SubModuleA1Config]

und in der Tat SomeBean - Klasse zurückgegeben wird, vom Kontext statt C1SomeBean. Dies ist eindeutig nicht das, was ich will.

InformationsquelleAutor Dawid Pytel | 2014-08-11
  1. 9

    Beachten Sie, dass Sie nicht außer Kraft setzen kann @Import erweitern configuration-Klassen.

    Wenn Sie auswählen möchten, die importiert verwenden Sie zur Laufzeit könnte ein @ImportSelector statt.

    Jedoch @Configuration sind die Klassen nicht mehr, dass der Frühling (scoped) verwaltete Fabriken, so wie Sie bereits über eine factory-Methode für someBean Sie nicht brauchen, um noch weiter zu gehen:

    @Configuration
public class SubModuleA1Config {

@Autowired
private Environment env;

@Bean
public SomeBean someBean() {
      String customerProperty = env.getProperty("customer");
      if ("C1".equals(customerProperty))  
        return new C1SomeBean();

      return new SomeBean(); 

   }
}

    Update

    Mit einem ImportSelector:

    class CustomerImportSelector implements ImportSelector, EnvironmentAware {

    private static final String PACKAGE = "org.example.config";
    private static final String CONFIG_CLASS = "SubModuleConfig";

    private Environment env;

    @Override
    public String[] selectImports(AnnotationMetadata importingClassMetadata) {
        String customer = env.getProperty("customer");
        return new String[] { PACKAGE +  "." + customer + "." + CONFIG_CLASS };
    }

    @Override
    public void setEnvironment(Environment environment) {
        this.env = environment;
    }
}

@Configuration
@Import(CustomerImportSelector.class) 
public class ModuleAConfig {
    //some module level beans
}

    Jedoch, wie jeder Kunde hat ein separates Paket, überlegen Sie auch, mit @ComponentScan. Diese Holen die configuration-Klasse vorhanden und brauchen nicht ein extra configuration-Eigenschaft.

    @Configuration
@ComponentScan(basePackages="org.example.customer")
public class SubModuleA1Config {

    @Autowired
    private CustomerFactory customerFactory;

    @Bean
    public SomeBean someBean() {
        return customerFactory.someBean();
   }
}

public interface CustomerFactory {
    SomeBean someBean();
}

@Component
public class C1CustomerFactory implements CustomerFactory {

    @Override
    public SomeBean someBean() {
        return new C1SomeBean();
    }
}
    • Ich würde es vorziehen, Kunden-spezifische Konfiguration an einem Ort, sondern wird verstreut in alle verschiedenen Konfigurations-Klassen. Außerdem, wenn es mehr als 3 Kunden, die so einen code nicht gut Aussehen. Drittes argument gegen ist, dass jedes Paket, das ich liefern, müssen alle Codes für alle Kunden (es sei denn, ich benutze Reflexionen, die macht die Lösung noch hässlicher). Würde ich gerne liefern nur core+C1 code Customer1. Aber @ImportSelector könnte nützlich sein bei der Erreichung dieser Modularisierung. Wie würdest du es anwenden, um das Ergebnis zu erhalten? Es gibt sehr wenige Beispiele zu verwenden.
    • siehe update.
    • In Bezug auf die import-Wahlschalter ich sehe die Idee, aber IMHO hätte ich noch ein problem der Vererbung in der Konfiguration-Klassen und nicht-Kunden-bean übergeordneten Kunden ein. Wahrscheinlich bessere Idee wäre die Umsetzung DeferredImportSelector ausführen import am Ende, wenn die nicht-Kunden-die Konfiguration ist bereits geladen. Diese Weise Kunden-Konfiguration überschreiben nicht-Kunden ein. In Bezug auf die "factory-Lösung" es funktioniert, wenn ich gut definiert haben, legen Sie die Bohnen, die überschrieben werden können. In meinem Fall ist es wahr. Damit akzeptiert die Antwort. Ein Update: @Component public class C1CustomerFactory ...
    • Oh! danke für die Korrektur. Beachten Sie, dass legal ist, zu erweitern und überschreiben von bean-Methoden in eine Configuration-Klasse. Das problem ist, dass die Einfuhren von super-Klassen analysiert werden, zu.
    InformationsquelleAutor Jose Luis Martin
Schreibe einen Kommentar