Differenza tra applicationContext.xml e spring-servlet.xml in Spring Framework

  • In ogni caso, applicationContext.xml e spring-servlet.xml correlati in Spring Framework?
  • I file delle proprietà dichiarati in applicationContext.xml saranno disponibili per DispatcherServlet ?
  • Su una nota correlata, perché ho bisogno di un *-servlet.xml ? Perché applicationContext.xml da solo non è sufficiente?

Spring consente di definire più contesti in una gerarchia padre-figlio.

applicationContext.xml definisce i bean per il “contesto webapp root”, ovvero il contesto associato alla webapp.

spring-servlet.xml (o qualsiasi altra cosa tu chiami) definisce i bean per il contesto dell’app di una servlet. Possono esserci molti di questi in una webapp, una per servlet Spring (es. spring1-servlet.xml per servlet spring1 , spring2-servlet.xml per servlet spring2 ).

I bean in spring-servlet.xml possono fare riferimento a bean in applicationContext.xml , ma non viceversa.

Tutti i controller MVC Spring devono essere spring-servlet.xml contesto spring-servlet.xml .

Nella maggior parte dei casi semplici, il contesto applicationContext.xml non è necessario. Generalmente viene utilizzato per contenere i bean condivisi tra tutti i servlet in una webapp. Se hai solo un servlet, allora non c’è davvero molto senso, a meno che tu non ne abbia un uso specifico.

scenario 1

Nell’applicazione client (l’applicazione non è un’applicazione Web, ad esempio l’app per swing)

 private static ApplicationContext context = new ClassPathXmlApplicationContext("test-client.xml"); context.getBean(name); 

Non c’è bisogno di web.xml . ApplicationContext come contenitore per ottenere il servizio bean. Nessuna necessità di contenitore del server web. In test-client.xml può esserci un bean semplice senza remoting, bean con remoting.

Conclusione : nello scenario 1 applicationContext e DispatcherServlet non sono correlati.

Scenario 2

In un’applicazione server (applicazione distribuita nel server, ad es. Tomcat). Servizio accessibile tramite servizio remoto dal programma client (ad es. App Swing)

Definisci listener in web.xml

  org.springframework.web.context.ContextLoaderListener  

All’avvio del server ContextLoaderListener crea un’istanza di bean definita in applicationContext.xml .

Supponendo che tu abbia definito quanto segue in applicationContext.xml :

     

I bean vengono istanziati da tutti e quattro i file di configurazione test1.xml , test2.xml , test3.xml , test4.xml .

Conclusione : nello scenario 2 applicationContext e DispatcherServlet non sono correlati.

Scenario 3

In un’applicazione Web con MVC a molla.

Nel web.xml definisci:

  springweb org.springframework.web.servlet.DispatcherServlet   springweb *.action  

All’avvio di Tomcat, i bean definiti in springweb-servlet.xml vengono istanziati. DispatcherServlet estende FrameworkServlet . In FrameworkServlet istanziazione dei bean ha luogo per springweb. Nel nostro caso springweb è FrameworkServlet.

Conclusione : nello scenario 3 applicationContext e DispatcherServlet non sono correlati.

Scenario 4

Nell’applicazione Web con MVC a molla. springweb-servlet.xml per servlet e applicationContext.xml per l’accesso al servizio aziendale all’interno del programma server o per l’accesso al servizio DB in un altro programma server.

Nel web.xml sono definiti i seguenti:

  org.springframework.web.context.ContextLoaderListener   springweb org.springframework.web.servlet.DispatcherServlet   springweb *.action  

All’avvio del server, ContextLoaderListener crea un’istanza di bean definita in applicationContext.xml ; assumendo che tu abbia dichiarato qui:

     

I bean sono tutti istanziati da tutti e quattro test1.xml , test2.xml , test3.xml , test4.xml . Dopo il completamento dell’istanza di bean definita in applicationContext.xml, i bean definiti in springweb-servlet.xml vengono istanziati.

Quindi l’ordine di istanziazione è root è il contesto dell’applicazione, quindi FrameworkServlet.

Ora chiarisce perché sono importanti in quale scenario.

Un altro punto che voglio aggiungere. In spring-servlet.xml includiamo la scansione dei componenti per il pacchetto Controller. Nell’esempio seguente includiamo l’annotazione del filtro per il pacchetto controller.

     

In applicationcontext.xml aggiungiamo il filtro per il pacchetto rimanente escluso il controller.

    

In parole semplici,

applicationContext.xml definisce i bean condivisi tra tutti i servlet. Se l’applicazione ha più di un servlet, la definizione delle risorse comuni nel file applicationContext.xml potrebbe avere più senso.

spring-servlet.xml definisce i bean che sono relativi solo a quel servlet. Qui è il servlet dispatcher. Quindi, i tuoi controller Spring MVC devono essere definiti in questo file.

Non c’è nulla di sbagliato nel definire tutti i bean in spring-servlet.xml se si sta eseguendo solo un servlet nella propria applicazione web.

I contesti delle applicazioni forniscono un mezzo per risolvere i messaggi di testo, incluso il supporto per i18n di quei messaggi. I contesti delle applicazioni forniscono un modo generico per caricare risorse di file, come le immagini. I contesti delle applicazioni possono pubblicare eventi per i bean registrati come listener. Alcune operazioni sul contenitore o sui bean nel contenitore, che devono essere gestite in modo programmatico con un bean factory, possono essere gestite in modo dichiarativo in un contesto applicativo. Supporto ResourceLoader: Spring’s Resource ci interfaccia un’astrazione generica flessibile per la gestione di risorse di basso livello. Un contesto applicativo stesso è un ResourceLoader, quindi fornisce un’applicazione con accesso a istanze di risorse specifiche della distribuzione. Supporto MessageSource: il contesto applicativo implementa MessageSource, un’interfaccia utilizzata per ottenere messaggi localizzati, con l’implementazione effettiva inseribile

Nella tecnologia Servlet, se si desidera passare qualsiasi input a un particolare servlet, è necessario passare in init param come sotto il codice.

   DBController com.test.controller.DBController  username John  1   DBController /DBController  

Se si vuole passare un po ‘in put che è comune a tutti i servlet allora quella volta è necessario configurare il parametro context. Esempio

   email [email protected]  

COSÌ esattamente come questo quando lavoriamo con Spring MVC, dobbiamo fornire alcune informazioni al servlet predefinito fornito da Spring che è DispatcherServlet tramite init param. Quindi la configurazione è come fallows, qui stiamo fornendo spring-servlet.xml come parametro init a DispatcherServlet.

    Spring MVC App  SpringController org.springframework.web.servlet.DispatcherServlet  contextConfigLocation /WEB-INF/spring-servlet.xml  1   SpringController *.htm   

Ancora una volta abbiamo bisogno di alcuni parametri di contesto. Questo è applicabile per l’intera applicazione. Quindi possiamo fornire il contesto di root che è applicationcontext.xml La configurazione è così:

   contextConfigLocation /WEB-INF/applicationcontext.xml   org.springframework.web.context.ContextLoaderListener   SpringController org.springframework.web.servlet.DispatcherServlet  contextConfigLocation /WEB-INF/spring-servlet.xml  1   SpringController *.htm