Spring-MVC: cosa sono "contesto" e "spazio dei nomi"?

Question

Da XmlWebApplicationContext javadoc:

Per default, la configurazione sarà preso da "/WEB-INF/applicationContext.xml" per il contesto radice, e "/WEB-INF/test-servlet.xml" per un contesto con lo spazio dei nomi "test-servlet" (come per un'istanza DispatcherServlet con il nome-servlet "test").

Che cosa significa un contesto di primavera?

Qual è il contesto di root? Quali altri tipi di contesto di primavera ci sono?

Che cos'è un namespace?

UPDATE:

Alcune domande di follow-up:

1. Che cosa è una molla ApplicationContext - è qualche "cosa" che contiene i fagioli che si definiscono in un file XML di configurazione?

2. Guardando il codice di ContextLoaderListener, sembra che carichi i dati definiti nei file XML di configurazione. Ma la mia app web Spring funziona senza definire questo listener o qualsiasi altro listener. Come potrebbe essere?

3. In quali scenari avrebbe senso avere più di un'istanza di DispatcherServlet di Spring?

4. Il contesto di root (dati da applicationContext.xml) è applicabile a ogni istanza di DispatcherServlet, mentre altri contesti (ad esempio dati da test-servlet.xml) sono applicabili solo al DispatcherServlet pertinente (cioè test)?

Answer 1

"Contesto di primavera" = a Spring ApplicationContext.

"contesto radice", in termini di un'applicazione Web, indica il contesto principale che viene caricato e utilizzato dalla webapp. In genere, si avvia il contesto di root con uno ContextLoaderListener.

Il contesto radice non è realmente un "tipo" di contesto. È solo un ruolo che gioca un contesto. Hai un contesto di root in una webapp. Altri contesti non sono il contesto di root. Di solito sono bambini del contesto di root.

Uno spazio dei nomi qui fa riferimento all'ambito di un'istanza di Spring DispatcherServlet. Tutto quello che dice è che se si assegna il nome "test" al proprio servlet nel proprio web.xml, per convenzione, Spring cercherà un file denominato "test-servlet.xml" da utilizzare come contesto del dispatcher. Per inciso, ogni contesto come questo creato per un dispatcher diventa figlio del contesto di root.

Edit: per rispondere alle vostre domande nuove:

1. seguire il link nella prima riga della mia risposta per conoscere l'ApplicationContext. Se hai domande a cui non hai risposto, ti suggerirei di pubblicare una nuova domanda SO.
2. Il contesto di root è facoltativo. Se non hai definito ContextLoaderListener, allora non hai un contesto di root.Quando si utilizza DispatcherServlet, avvia il proprio ApplicationContext e otterrà da lì i bean necessari.
3. Non so di uno al largo della parte superiore della mia testa. Suppongo che ci fosse la necessità di configurazioni drasticamente diverse tra alcune delle risorse URL nella tua app, che potrebbero spingerti a farlo.
4. Sì. Per indicarlo nei termini appropriati, il contesto di root è il contesto genitore di qualsiasi contesto avviato per DispatcherServlet. I bean in un contesto padre sono accessibili attraverso e dal contesto figlio, ma il contrario non è vero.

Answer 2

In un'applicazione Web, l'architettura è solitamente divisa in livelli come la struttura MVC popolare. Quindi una web app comprende essenzialmente di uno strato che gestisce le richieste dei client cioè HTTPRequests e uno strato che i servizi di tali richieste.

In sintesi: le classi che hanno lo scopo di gestire le richieste HTTP cioè i controllori che sono mappati agli URL venire sotto il test-servlet.xml. Questo è chiamato come WebapplicationContext che contiene solo i bean che sono richiesti principalmente per gestire le richieste del client.

Ora la parte successiva è il livello di servizio/Dao che si compone della logica di business. I bean che eseguono tale logica vengono caricati nell'oggetto ApplicationContext.

Ora si può chiedere perché hanno separato queste cose ai file o due oggetti diversi.

suo perché, un'applicazione hanno la stessa logica di business che può essere utilizzato da più client che lavorano su protocollo diverso. È possibile utilizzare gli stessi livelli di servizio per gestire RMI e le chiamate HTTP. Quindi Spring ha creato un contesto padre che ci ha avviato come ApplicationContext. E poi se le vostre richieste web di applicationhandles, potete creare un servlet di dispathcher che ha il proprio Webapplicationcontext e inizializzato come figlio del contesto genitore. Quindi tutti i bean parent possono essere referenziati nel child e possono essere overiden ma non viceversa