Dovrei annotare la classe di configurazione come @Configuration per il test?

Question

Ho trascorso un po 'di tempo risolvere il problema con il convertitore org.joda.time.DateTime->java.util.Date mancante nei dati di primavera (che dovrebbe essere abilitato per impostazione predefinita quando Joda-Time è su un classpath). Ho trovato una ragione, ma ha generato una domanda sull'annotazione @Configuration in primavera.

Applicazione standard Config utilizzando AbstractMongoConfiguration da Spring-Data-MongoDB:

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

.

Un test che utilizza l'esplicita classe AppConfig (con Spock, ma vengono utilizzati meccanismi internamente forniti da Spring-Test):

@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
    }
}

.

funziona bene. Ma quando @Configuration annotazione in appconfig è rimosso / commentato:

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

.

Il test non riesce con:

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

.

AFAIK Non è necessario utilizzare @Configuration per la classe di configurazione quando è esplicita registrata nel contesto (per classi in @ContextConfiguration o un metodo register() in AnnotationConfigWebApplicationContext). Le lezioni vengono elaborate comunque e tutti i fagioli dichiarati vengono trovati. A volte è utile per non utilizzare @Configuration per impedire il rilevamento da una scansione del componente quando ci sono 2 classi di configurazione simili negli stessi pacchetti in un contesto di test utilizzato da diversi test.

Di seguito penso che possa un bug in primavera che provoca un diverso elaborazione di fagioli interni nel contesto a seconda dell'utilizzo o non un'annotazione @Configuration. Ho confrontato i registri di primavera da questi due casi e ci sono alcune differenze, ma non sono in grado di determinare cosa sono causati dalle classi interne della primavera. Prima di una sottomissione del bug vorrei chiedere:

La mia domanda. Esistono un motivo esplicabile per cui la primavera per la stessa classe di configurazione (applicita in evidenza in @ContextConfiguration) utilizza i convertitori (o meno) per Joda-Time a seconda dell'esistenza di un'annotazione @Configuration?

Ho creato anche un Progetto QuickStart Riproducendo il problema. Spring-data-mongodb 1.3.3, Spring 4.0.0, Joda-Time 2.3.

Answer 1

È tutto ok in questo comportamento.AbstractMongoConfiguration è annotato da @Configuration, ma in realtà questa annotazione non è @Inherited, quindi devi annullare esplicitamente la tua classe.

Quando si rimuove l'annotazione @Configuration, la classe AppConfig non è una configurazione Full .Sono processi come una configurazione Lite solo perché contiene metodi annotati da @Bean - Si prega di fare riferimento ai metodi in org.springframework.context.annotation.ConfigurationClassUtils

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

Infine solo Full (Annotato da @Configuration) Le classi di configurazione sono processi e migliorati dai processori post di configurazione - Guarda ConfigurationClassPostProcessor.enhanceConfigurationClasses()