Dove vanno i file di configurazione del bean Spring in un modulo Maven WAR?

Question

Ho esaminato una serie di progetti di esempio e non riesco a mettere in evidenza una pratica comune comune. Ho visto che i file di configurazione dei bean Spring talvolta entrano nella directory src/main/webapp/WEB-INF. Ho visto questo in collaborazione con con una definizione Servlet in web.xml come questo:

<servlet> 
    <servlet-name>my-stuff</servlet-name> 
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> 
    <init-param> 
     <param-name>contextConfigLocation</param-name> 
     <param-value>/WEB-INF/my-stuff-servlet.xml</param-value> 
    </init-param> 
    <load-on-startup>1</load-on-startup> 
</servlet> 

Ma ho visto anche i file di configurazione di fagioli inclusi all'interno web.xml livello superiore - vale a dire al di fuori di un Servlet. Cosa significa questo? E 'questo per i fagioli cross-servlet? A volte è nella directory src/main/webapp/WEB-INF ea volte è in src/main/resources. Inoltre ho visto altri file di configurazione dei bean definiti nei moduli WAR con quasi tutto in src/main/resources.

Ho letto e riletto la documentazione Spring, ma l'unica convenzione che ho trovato è che per impostazione predefinita un file di configurazione del contesto Servlet deve essere nella directory src/main/webapp/WEB-INF denominata {servlet-name}-servlet.xml.

Allora, qual è la migliore pratica e perché?

Answer 1

I contesti di applicazione in Spring possono formare gerarchie in cui il contesto figlio ha accesso ai bean definiti nel contesto padre.

Una tipica applicazione web Spring MVC contiene una gerarchia con due livelli:

• root di contesto dell'applicazione web caricato da ContextLoaderListener. La posizione di configurazione di questo contesto è applicationContext.xml per impostazione predefinita e può essere configurata utilizzando <context-param> denominata contextConfigLocation, ad esempio al livello superiore di web.xml. Questo contesto di solito contiene una logica di base dell'applicazione.

• Contesto specifico servlet caricato da DispatcherServlet. La sua posizione di configurazione è <servletname>-servlet.xml predefinita e può essere configurata utilizzando <init-param> denominata contextConfigLocation, ad esempio a livello di servlet. Questo contesto di solito contiene un materiale relativo a Spring MVC (controller, ecc.) Poiché DispatcherServlet è una parte di Spring MVC.

Quest'ultimo contesto è figlio del primo.

Se l'applicazione Web non utilizza Spring MVC come framework di presentazione, non dispone di DispatcherServlet e del relativo contesto. Alcuni esempi di MVC primaverili estremamente semplici non hanno ContextLoaderListener e il contesto di root (tuttavia, è necessario il contesto di root per funzionalità di servlet come Spring Security).

I file di configurazione dell'applicazione Web si trovano di default nella cartella principale di webapp. Tuttavia, possono essere inseriti nel classpath (ad esempio in src/main/webapp), in questo caso sono accessibili tramite il prefisso classpath:. Ciò può essere utile se si intende utilizzare alcuni di questi file nei test di integrazione senza contenitore servlet. Il prefisso classpath: può essere utile quando si desidera caricare un file di configurazione da un artefatto separato, ad esempio da un file jar in /WEB-INF/lib.

Answer 2

Penso che sia spesso un buon stile mantenere il codice, la sua configurazione di primavera in un JAR separato incluso in WAR, in modo che WAR sia fondamentalmente vuoto ma per web.xml e simili. Questo ti evita persino di fare questa domanda. :-) Puoi fare riferimento a quelle configurazioni di molle con classpath: prefisso.

Un vantaggio di questo layout è che è possibile scrivere facilmente Unittest che istanzia l'intera configurazione Spring di WAR all'interno del JAR. Non consiglierei assolutamente di usarlo per i test effettivi (sebbene sia possibile eseguire test di integrazione in questo modo), ma si ottiene un feedback rapido quando si interrompe accidentalmente la struttura generale dei file di configurazione senza dover ridistribuire l'applicazione.

Se è davvero necessario inserire i file di configurazione di primavera in WAR (forse poiché fa riferimento anche ai bean implementati nello stesso WAR), li inserirò anche nel normale percorso delle risorse/WEB-INF/classes, per il ragioni discusse sopra.