2013-10-15 6 views
6

Sto usando l'annotazione @ContextConfiguration per gestire le configurazioni nella mia applicazione. Le configurazioni sono create in modo tale da fornire solo i bean che sono esposti da quel dato modulo. Per questo motivo, alcuni bean utilizzati dal modulo specificato non vengono necessariamente importati direttamente. Esempio:L'ordine di inizializzazione delle classi di configurazione in @ContextConfiguration può essere influenzato?

configuration --(use)--> module1 --(cannot @Import)--> database 
       \-(use)--------------------------------> database 

A parole, la configuration utilizza module1 che richiede (ma non bisogna importare direttamente) la configurazione del database. Pertanto, configuration utilizza anche il modulo database.

Ma sembra che l'ordine in cui vengono risolte le importazioni sia piuttosto casuale. Anche se uso

@ContextConfiguration(classes={DatabaseConfig.class, Module1Config.class}) 

Ciò si traduce in un fallimento indeterministica su di inizializzazione (NoSuchBeanDefinitionException).

C'è un modo per influenzare l'ordine in cui i bean sono inizializzati? O dovrei creare una sovrapposizione di configurazioni che @Import le configurazioni lungo le dipendenze? Ma in questo caso la stessa domanda si applica a @Import in quanto deve garantire l'ordine in cui vengono caricate le dipendenze.

risposta

1

Questo problema sembra derivare dalle diverse versioni di primavera che sono disponibili allo stesso tempo. Quando il codice è stato lasciato in esecuzione, solo una frazione di @Imports è stata caricata con il metodo org.springframework.context.annotation.ConfigurationClassParser.collectImports(‌​AnnotationMetadata, Set<Object>, Set<Object>). Quando l'esecuzione è stata sospesa da un punto di interruzione durante l'analisi, tutto ha funzionato perfettamente.

Non appena le versioni multiple delle librerie a molla sono state pulite su, il problema è andato via. (Almeno non è ricomparso dopo una dozzina circa).

0

Penso che dovresti usare l'annotazione @DependsOn - progettata esattamente per questi casi.

+0

Sfortunatamente, l'annotazione @DependsOn rende esplicita la dipendenza ma non causa il backtracking per caricare eventualmente i bean mancanti da altre configurazioni. – allprog

+0

Quale vero problema si prova a risolvere e perché i bean dipendenti non dovrebbero essere descritti come dipendenti nella configurazione (potrebbe essere tramite interfacce)? –

+0

Se includo la configurazione del DB nella configurazione dei moduli che la usano, allora sarà impossibile cambiare quella definizione del DB in qualcos'altro. Ad esempio, se voglio mettere a fuoco i miei test unitari su un modulo di livello superiore, cerco di evitare di caricare il DB e cercare di interrompere l'albero delle dipendenze il prima possibile. O creo diverse configurazioni per il test e la produzione o creo le configurazioni in modo mirato ed evito le dipendenze di importazione tra di loro, in questo modo nei test posso selezionare ciò che carico. – allprog

Problemi correlati