Soll ich die Konfigurationsklasse zum Testen als @Configuration annotieren?

Question

Ich habe einige Zeit damit verbracht, das Problem mit dem Fehlen zu lösen org.joda.time.DateTime->java.util.Date konverter in Frühlingsdaten (der standardmäßig aktiviert sein sollte, wenn sich Joda-Time in einem Klassenpfad befindet).Ich habe einen Grund gefunden, aber es wurde eine Frage zu @Configuration annotation im Frühjahr.

Standardanwendungskonfiguration mit AbstractMongoConfiguration von spring-Daten-mongodb:

@Configuration
@ComponentScan
@EnableMongoRepositories
public class AppConfig extends AbstractMongoConfiguration { ... }

Ein Test, der explizit die AppConfig-Klasse verwendet (mit Spock, aber intern werden Mechanismen verwendet, die von spring-Test bereitgestellt werden):

@ContextConfiguration(classes = AppConfig)
class JodaDocRepositorySpec extends Specification {

    @Autowired
    private JodaDocRepository jodaDocRepository

    def "save document with DateTime"() {
        given:
            def jodaDoc = new JodaDoc(DateTime.now())
        when:
            def savedJodaDoc = jodaDocRepository.save(jodaDoc)
        then:
            savedJodaDoc.id
    }
}

Es funktioniert gut.Aber wenn @Configuration Annotation in AppConfig ist entfernen/kommentiert:

//@Configuration
@ComponentScan
@EnableMongoRepositories
public class AppConfig extends AbstractMongoConfiguration { ... }

der Test schlägt fehl mit:

org.springframework.core.convert.ConverterNotFoundException:
No converter found capable of converting from type org.joda.time.DateTime to type java.util.Date

AFAIK wird nicht benötigt, um zu verwenden @Configuration für die Konfigurationsklasse, wenn sie explizit im Kontext registriert ist (nach Klassen in @ContextConfiguration oder ein register() methode in AnnotationConfigWebApplicationContext).Die Klassen werden trotzdem verarbeitet und alle deklarierten Beans werden gefunden.Es ist manchmal nützlich, nicht zu verwenden @Configuration um zu verhindern, dass durch einen Komponentenscan erkannt wird, wenn sich 2 ähnliche Konfigurationsklassen in denselben Paketen in einem Testkontext befinden, der von verschiedenen Tests verwendet wird.

Daher denke ich, dass es ein Fehler im Frühjahr sein könnte, der zu einer unterschiedlichen internen Bean-Verarbeitung im Kontext führt, abhängig von einer Verwendung oder nicht @Configuration Anmerkung.Ich habe Spring-Protokolle aus diesen beiden Fällen verglichen und es gibt einige Unterschiede, aber ich kann nicht feststellen, woran sie in den internen Spring-Klassen liegen.Vor einer Fehlermeldung möchte ich fragen:

Meine Frage. Gibt es einen erklärbaren Grund, warum Spring für dieselbe Konfigurationsklasse (explizit angegeben in @ContextConfiguration) verwendet (oder nicht) Konverter für die Joda-Zeit, abhängig von der Existenz eines @Configuration anmerkung?

Ich habe auch eine erstellt schnellstart-Projekt reproduzieren des Problems.frühlingsdaten-mongodb 1.3.3, Frühling 4.0.0, Joda-Zeit 2.3.

Answer 1

Bei diesem Verhalten ist alles in Ordnung. AbstractMongoConfiguration wird kommentiert von @Configuration, aber tatsächlich ist diese Anmerkung nicht @Inherited, also müssen Sie Ihre Klasse explizit mit Anmerkungen versehen.

Wenn Sie entfernen @Configuration anmerkung dann Ihre AppConfig klasse ist keine voll Konfiguration.Es sind Prozesse als Lite konfiguration, nur weil sie Methoden enthält, die mit Anmerkungen versehen sind @Bean - bitte beachten Sie die Methoden in org.springframework.context.annotation.ConfigurationClassUtils

• isFullConfigurationCandidate()
• isLiteConfigurationCandidate()
• isFullConfigurationClass()

Endlich nur noch voll (kommentiert von @Configuration) konfigurationsklassen sind Prozesse und werden durch Konfigurations-Postprozessoren erweitert - siehe ConfigurationClassPostProcessor.enhanceConfigurationClasses()