Wie überschreibt man eine Spring @Autowire-Annotation und setzt ein Feld auf null?

Question

Ich bin ein Spring-Neophyt, der an einem großen Spring-basierten Projekt arbeitet, das eine umfangreiche Kopplung zwischen Spring Beans hat. Ich versuche, einige Integrationstests zu schreiben, die Teilmengen der gesamten Anwendungsfunktionalität ausführen. Um dies zu tun, möchte ich etwas vom Autowiderstand überschreiben. Angenommen, ich habe eine Klasse

public class MyDataServiceImpl implements MyDataService { 
    @Qualifier("notNeededForMyDataServiceTest") 
    @Autowired 
    private NotNeededForMyDataServiceTest notNeededForMyDataServiceTest; 
    //... 
} 

und eine Kontext-Datei mit:

<bean id="myDataService" 
     class="MyDataServiceImpl"> 
</bean> 

In meinem Test habe ich keine Notwendigkeit, das notNeededForMyDataServiceTest Feld zu verwenden. Gibt es eine Möglichkeit, die @Autowired Annotation zu überschreiben und notNeededForMyDataServiceTest auf null setzen, vielleicht in der XML-Datei? Ich möchte keine der Java-Klassen ändern, aber ich möchte die (problematische) Konfiguration von notNeededForMyDataServiceTest vermeiden.

Ich habe versucht zu tun:

<bean id="myDataService" 
     class="MyDataServiceImpl"> 
    <property name="notNeededForMyDataServiceTest"><null/></property> 
</bean> 

, das nicht funktioniert. IntelliJ informiert mich, dass die Eigenschaft 'notNeededForMyDataServiceTest' nicht aufgelöst werden kann, offenbar weil für dieses Feld keine Getter und Setter vorhanden sind.

Ich benutze Spring Framework 3.1.3.

Answer 1

Die folgende Konfiguration arbeiten soll, nahm ich die Freiheit in Java-Konfiguration des Mischens

@Configuration 
//This will load your beans from whichever xml file you are using 
@ImportResource("classpath:/path/beans.xml") 
public class TestConfigLoader{ 
    // This will declare the unused bean and inject MyDataServiceImpl with null. 
    public @Bean(name="notNeededForMyDataServiceTest") NotNeededForMyDataServiceTest getNotNeededForMyDataServiceTest(){ 
     return null; 
    } 
... any other configuration beans if required. 
} 

Und Ihre Testklasse mit Anmerkungen versehen, wie so:

// In your test class applicationContext will be loaded from TestConfigLoader 
@ContextConfiguration(classes = {TestConfigLoader.class}) 
public class MyTest { 
    // class body... 
} 

Answer 2

Diese könnten helfen:

• Context configuration with annotated classes
• Testing with @Configuration Classes and Profiles
• Spring TestContext Framework

und Profile:

• beans profile="..."
• Introducing @Profile

Sie verschiedene Bohnen Definition in der XML-Konfiguration erstellen könnte und dann aktivieren sie die -Dspring.profiles.active="profile1,profile2" env verwenden.

Answer 3

Sie verwenden den @Autowired Mechanismus falsch. Das Qualifikationsmerkmal ist nicht eine Eigenschaft, die Sie festlegen müssen. Das ist eigentlich der Name einer Bean, so dass der Container eine bestimmte Instanz auswählen kann, falls mehrere Beans desselben Typs im selben Kontext definiert sind.

So sucht der Container nach einer Bean vom Typ NotNeededForMyDataServiceTest und dem Namen (der in XML eigentlich die Bean id wäre): notNeededForMyDataServiceTest.

Was ich denke, dass Sie möchten, ist der Container angewiesen, nichts in dieses Feld zu injizieren, wenn keine Bean des Typs NotNeededForMyDataServiceTest im Anwendungskontext definiert ist.

@Autowired(required = false) 
NotNeededForMyDataServiceTest someOptionalDependency; 

Der einzige Nachteil dieses Ansatzes wäre, dass der Behälter nie zur Laufzeit beschweren, wenn es nichts in diesem Bereich zu injizieren (und vielleicht: Das könnte einfach durch Setzen des required Attributs der Anmerkung zu false erreicht werden Sie möchten diese Plausibilitätsprüfung, wenn Ihr Code in der Produktion ausgeführt wird.

---

Wenn Sie nicht, dass die Abhängigkeit optional machen wollen (oder Sie können nicht, dass Code aus irgendeinem Grunde bearbeiten), werden Sie einen Mock/null Wert für das Feld zur Verfügung stellen müssen, damit explizit einstellen in deinem Kontext. Eine Möglichkeit dazu wäre die Verwendung der Java-Konfiguration anstelle von XML (wie in der Antwort von @ Abe), und ein anderer Ansatz wäre die Verwendung einer Factory-Bean, die null (wie in this question) zurückgibt.