Scopo e relazione dei diversi contesti in primavera

Question

Sto utilizzando un progetto di avvio a molla. Voglio capire lo scopo e la relazione di diversi contesti?

Per esempio, il contesto Primavera di sicurezza, Contesto Primavera, Servlet Context, ecc (Ci sono altri contesti?)

Answer 1

Non ci possono essere diverse interpretazioni, ma ecco come la vedo io:

contesto

• Primavera di sicurezza, nel significato di SecurityContext classe, detiene i autenticazione, nome utente, autorità (ruoli) ed eventualmente altre informazioni sull'utente corrente. La durata di tale contesto è la richiesta corrente o il contesto di sicurezza è persistente tra le richieste che utilizzano le sessioni.

• Contesto di primavera, nel significato della classe ApplicationContext, è il punto centrale di un'applicazione Spring in esecuzione. Il suo scopo principale è quello di contenere i bean singleton dell'app, ma ha molte altre caratteristiche eleganti (diverse sono citate in un'altra risposta). Un'applicazione può avere diversi ApplicationContexts, ma il caso più comune e più semplice, ne ha solo uno. Le applicazioni Web di solito utilizzano l'estensione "WebApplicationContext", che la integra con il contesto Servlet.

• Servlet Context, il significato di ServletContext di classe, è il contesto a livello di applicazione di una webapp Servlet ha. Esiste sempre esattamente una per istanza webapp in un contenitore di servlet come Tomcat. Non fa parte della primavera. Raramente lo usi direttamente quando usi Spring. Ma è lì sullo sfondo.

"Contesto" è piuttosto un termine generico, così ci possono essere altri contesti anche nel proprio ambiente.

Answer 2

Ci sono molti "contesti" e come essi vengono caricati dipende da come si inizializza l'applicazione. Ma normalmente la maggior parte delle applicazioni ha un unico contesto che contiene tutti i bean e i componenti richiesti dall'applicazione.

Ad esempio, se è stata caricata un'applicazione utilizzando un servlet, è possibile caricare l'intero con un "contesto root" che carica anche il contesto servlet come se fosse figlio.

La gerarchia è come la seguente "root" context ->any other context. È così semplice.

Un descritto here in the Spring DocsApplicationContext dispone:

• Bean metodi di fabbrica per l'accesso ai componenti dell'applicazione. (Fancy talk per le cose che ti servono nella tua applicazione senza usare new() chiamato dependency injection)
• La possibilità di caricare le risorse di file in modo generico. (Configurazione esterna con properties e profiles)
• La possibilità di pubblicare eventi su listener registrati. (I fantasiosi commenti su "quando accadono certe cose fanno qualcosa", leggi su observer pattern)
• La capacità di risolvere i messaggi per supportare l'internazionalizzazione. (I file con tutte le stringhe utilizzate nell'applicazione in modo che possano essere visualizzati in diverse lingue, leggi circa MessageSource)
• Ereditarietà da un contesto padre. (Come ho detto prima, le vostre esigenze applicative "contesto" e questo è dove inizia.)

Come si utilizza avvio primavera, c'è solo un contesto di default: ApplicationContext. Questo conterrà tutte le tue cose (fagioli) e componenti necessari.

Questo è il bello dell'utilizzo di Avvio a molla, configurazione minima e configurazione semplificata. Se ritieni di aver bisogno di più contesti, ti esorto a utilizzare invece Profiles.

In definitiva, il "contesto" viene creato e definito dall'applicazione, pensarlo come una configurazione (sia XML che Java) che definisce l'applicazione. cosa c'è "in esso" e cosa "ha bisogno" di lavorare.

Se si desidera provare a capirlo di più, vorrei esortare a leggere dall'inizio e iniziare con lo Introduction to Spring.

Answer 3

In termini di progettazione del sistema, qualsiasi contesto è una raccolta di funzionalità e dati comuni, definiti in un unico luogo, ma che devono essere utilizzati da qualsiasi punto del programma. E lo scopo principale di Context - ridurre il numero di dipendenze tra i componenti dell'applicazione. Un altro scopo di Context - semplificare l'accesso a funzionalità e dati comuni. Considera i contesti che hai elencato nella tua domanda.

ServletContext

ServletContext fa parte della Servlet technology. Molti dei framework sono basati su questa tecnologia (JSF, Spring, Struts e molti altri). ServletContext contiene funzionalità per comunicare con il suo contenitore Servlet (come Tomcat, Glassfish ecc.). Elementi di base che ServletContext fornisce:

• ottenere l'applicazione Parametri iniziali;
• ottenere informazioni sulla richiesta di dispacciamento;
• aggiungere o rimuovere servlet, filtri e ascoltatori;
• ottenere o impostare gli attributi del contenitore;
• messaggi di runtime del registro;
• ricevere ulteriori informazioni come percorso di applicazione, la versione contenitore ecc

Come potete vedere c'è solo funzionalità di base, che può essere utile in qualsiasi applicazione, se si vuole lavorare con la tecnologia Servlet (ad esempio, sviluppare un altro un framework mvc basato su di esso).

ApplicationContext

ApplicationContext è interfaccia principale Spring framework applicazione. Ha molte implementazioni. Uno di questi carica la configurazione dal file xml (ClassPathXmlApplicationContext), un altro carica la configurazione in base alle annotazioni (AnnotationConfigApplicationContext) e così via.Elementi di base che ApplicationContext fornisce:

• bean factory, possibilità di creare nuovi bean in base alle definizioni bean;
• carico risorse da diverse fonti (file system, file jar, url ecc.);
• possibilità di pubblicare ed ascoltare eventi;
• risolve i messaggi dai pacchetti di messaggi;

Ancora una volta, inizializzato all'avvio, questa funzionalità di base può essere utile quasi ovunque nella vostra applicazione. Questo è il motivo per cui è stato raccolto nel contesto. Molte classi utilizzate in background, per fornire queste capacità, ma tutto quello che dovete sapere, per utilizzare questa funzionalità - solo ApplicationContext.

SecurityContext

SecurityContext fornisce l'accesso ai dati di autenticazione. È possibile ottenere il nome dell'utente autenticato, i ruoli e altri dettagli. Questa informazione inizializzata dal modulo di sicurezza potrebbe essere necessaria in molti posti. I componenti, che utilizzano questa informazione, non conoscono le classi del modulo di sicurezza. Ricevono tutte le informazioni necessarie da SecurityContext.