Devo anotar classe de configuração como @Configuração para testes?

Question

Eu passei algum tempo na resolução de problema com falta de org.joda.time.DateTime->java.util.Date conversor na Primavera de Dados (que deve ser ativada por padrão quando Joda-Time é um classpath).Eu encontrei uma razão, mas é gerada uma pergunta sobre @Configuration anotação na Primavera.

Padrão de configuração do aplicativo usando AbstractMongoConfiguration a partir da primavera de dados mongodb:

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

Um teste que explícita usa AppConfig classe (com Spock, mas internamente mecanismos fornecidos pelo spring-teste são utilizados):

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

Ele funciona muito bem.Mas quando o @Configuração de anotação em AppConfig é removido/comentou:

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

o teste falhar com:

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

AFAIK, não é necessário para usar @Configuration para a classe de configuração quando é explícito registado no contexto (por classes de @ContextConfiguration ou um register() método em AnnotationConfigWebApplicationContext).As aulas são processados de qualquer maneira e todos declararam feijão são encontrados.Às vezes é útil para não usar @Configuration para evitar a detecção por um componente de digitalização, quando há 2 configuração semelhante classes nos pacotes para o mesmos em um teste de contexto utilizados por diferentes testes.

Os mesmos que eu acho que poderia um bug na Primavera, o que faz com que diferentes interno feijão processamento no contexto dependendo do uso ou não de um @Configuration anotação.Eu comparei a Primavera faz a partir de dois casos e existem algumas diferenças, mas eu não sou capaz de determinar o que são causados por na Primavera interna de classes.Antes de uma apresentação de erros eu gostaria de perguntar:

A minha pergunta. Há uma razão explicável por Mola, para a mesma classe de configuração (apontado explícito em @ContextConfiguration) usa (ou não) conversores para Joda-Time dependendo de uma existência de um @Configuration anotação?

Criei também um projeto de iniciação rápida reproduzir o problema.mola de dados mongodb 1.3.3, primavera 4.0.0, joda-time 2.3.

Answer 1

É tudo OK neste comportamento. AbstractMongoConfiguration é anotada por @Configuration, mas na verdade, esta anotação não é @Inherited, então você tem que explicitamente anotar sua classe.

Quando você remover @Configuration anotação, em seguida, seu AppConfig classe não é um completo de configuração.É o processo como um lite configuração só porque ele contém métodos anotados por @Bean - por favor, consulte métodos de org.springframework.context.annotation.ConfigurationClassUtils

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

Finalmente, apenas completo (anotado pelo @Configuration configuração classes são processos e reforçada pela configuração pós-processadores - olhar ConfigurationClassPostProcessor.enhanceConfigurationClasses()