Override default-lazy-init = true per le definizioni dei bean Spring

Question

Sto mantenendo un grande sistema Java EE. La maggior parte della logica aziendale viene convertita da EJB: s in POJO: s configurati in diversi file di configurazione del contesto di primavera. EJB: s sono principalmente utilizzati come facciate, che cercano i bean di primavera della logica aziendale da un contesto composto da tutti i file di configurazione del contesto di primavera menzionati in precedenza. Per questo usiamo il AbstractStatelessSessionBean fornito con la struttura di primavera.

Tutti questi file di configurazione hanno la direttiva default-lazy-init = true, il che significa che i bean di business logic non vengono creati finché non vengono effettivamente utilizzati dal sistema. Questo è preferibile la maggior parte del tempo poiché la ripubblicazione in modalità sviluppatore diventa più veloce.

Tuttavia, quando vengono effettuate fusioni di grandi dimensioni, si riscontrano problemi nel trovare tutti gli errori di configurazione, come le dipendenze mancanti.

La mia idea è di scrivere qualche forma di test di integrazione, con lo scopo di trovare quegli errori. Ciò significa, penso, che ho bisogno di trovare un modo per sovrascrivere tutte le dichiarazioni default-lazy-init = true durante la creazione del contesto dell'applicazione.

C'è un modo per farlo a livello di programmazione, o forse con un file di contesto di solo test che include tutti i file di contesto attuali?

Answer 1

Diciamo attualmente si dispone di un singolo applicationContext.xml file contenente tutte le definizioni di fagioli:

<beans default-lazy-init="true"> 

    <!-- all your beans --> 

</beans> 

rinominarlo in applicationContext-main.xml o qualcosa e rimuovere l'attributo default-lazy-init="true". Ora creare due file: applicationContext.xml

<beans default-lazy-init="true"> 

    <import resource="applicationContext-core.xml"/> 

</beans> 

e:

<beans default-lazy-init="false"> 

    <import resource="applicationContext-core.xml"/> 

</beans> 

Come si può vedere l'unica differenza è il valore di default-lazy-init. Durante lo sviluppo, il team può utilizzare la versione precedente di applicationContext.xml che include tutti i bean con lazy-init. Negli ambienti di staging e testing passare a quest'ultimo in modo che tutti i bean inclusi in applicationContext-core.xml vengano creati con entusiasmo.

Answer 2

Credo che il modo migliore per controllare lazy init di bean sia lasciare il default-lazy-init da tutti i file di configurazione eccetto quello più in alto come suggerisce Tomasz Nurkiewicz. In questo caso, tuttavia, ho avuto bisogno di una soluzione rapida e sporca per verificare tutte le definizioni dei bean. (E 'un po' di un processo di cambiare la politica di init pigro.)

mi si avvicinò con un semplice BeanFactoryPostProcessor che sembra fare il lavoro:

public class NonLazyInitBeanFactoryPostProcessor implements BeanFactoryPostProcessor { 
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException { 
     for (String beanName : beanFactory.getBeanDefinitionNames()) { 
      beanFactory.getBeanDefinition(beanName).setLazyInit(false); 
     } 
    } 
} 

Se inserite in un file di contesto, lo farà sovrascrivere il flag pigro di init impostato da qualsiasi file di contesto incluso.

<beans default-lazy-init="false"> 
    <bean class="example.NonLazyInitBeanFactoryPostProcessor" /> 
    <import resource="applicationContext-core.xml"/> 
</beans> 

Se cerco di creare un contesto dal XML qui sopra, errori di configurazione precedentemente nascoste da inizializzazione pigra mostrerà immediatamente come eccezioni.

Answer 3

C'è un 'ma' in questo PostProcessor

for (String beanName : beanFactory.getBeanDefinitionNames()) { 
     beanFactory.getBeanDefinition(beanName).setLazyInit(false); 
    } 

Questo ciclo for si iterare solo su top maggior parte dei fagioli non compreso e.g definizioni del bean interno (locale) ...

Answer 4

Non è possibile accedere allo scanner dal contesto: è completamente privato, ma dal momento che è possibile accedere al codice sorgente, è possibile visualizzare ciò che è necessario impostare personalmente. Ho usato proprio ReflectionTestUtils di primavera per impostare il mio scanner configurato nel contesto:

ClassPathBeanDefinitionScanner scanner = new ClassPathBeanDefinitionScanner(context); 
    BeanDefinitionDefaults defaults = new BeanDefinitionDefaults(); 
    defaults.setLazyInit(true); 
    scanner.setBeanDefinitionDefaults(defaults); 
    ReflectionTestUtils.setField(context, "scanner", scanner); 
    context.scan("com.some.path"); 

È possibile farlo ovunque ci sia accesso al contesto di applicazione prima della scansione dei componenti avviene.