web.xml vs Initializer with Spring

1. Oversikt

I denne artikkelen vil vi dekke tre forskjellige tilnærminger for å konfigurere en DispatcherServlet tilgjengelig i nyere versjoner av Vårramme:

  1. Vi begynner med en XML konfigurasjon og en web.xml fil
  2. Så migrerer vi Servlet-erklæringen fra web.xml fil til Java-konfigurasjon, men vi lar alle andre konfigurasjoner være inne XML
  3. Til slutt i det tredje og siste trinnet i refactoring, har vi et 100% Java-konfigurert prosjekt

2. Den DispatcherServlet

Et av kjernekonseptene til Vår MVC er den DispatcherServlet. Vårdokumentasjonen definerer det som:

En sentral avsender for HTTP-forespørsler / kontrollere, f.eks. for web-UI-kontrollere eller HTTP-baserte fjerntjenesteeksportører. Sendinger til registrerte håndtere for behandling av en nettforespørsel, og gir praktiske fasiliteter for kartlegging og unntakshåndtering.

I utgangspunktet DispatcherServlet er inngangspunktet for hver Vår MVC applikasjon. Hensikten er å fange opp HTTP forespørsler og å sende dem til riktig komponent som vet hvordan de skal håndtere den.

3. Konfigurasjon med web.xml

Hvis du takler arv Vår prosjekter det er veldig vanlig å finne XML konfigurasjon og til Vår 3.1 den eneste måten å konfigurere DispatcherServlet var med WEB-INF / web.xml fil. I dette tilfellet er det to trinn som kreves.

La oss se et eksempel på konfigurasjon - det første trinnet er Servlet-erklæringen:

 dispatcher org.springframework.web.servlet.DispatcherServlet contextConfigLocation /WEB-INF/spring/dispatcher-config.xml 1 

Med denne blokken av XML vi erklærer en servlet som:

  1. Heter "avsender
  2. Er en forekomst av org.springframework.web.servlet.DispatcherServlet
  3. Vil bli initialisert med en parameter som heter contextConfigLocation som inneholder banen til konfigurasjonen XML

belastning ved oppstart er en heltallverdi som spesifiserer rekkefølgen for flere servlets som skal lastes inn. Så hvis du trenger å erklære mer enn en servlet, kan du definere i hvilken rekkefølge de skal initialiseres. Servlets merket med lavere heltall lastes inn før servlets merket med høyere heltall.

Nå er servleten vår konfigurert. Det andre trinnet er å erklære en servlet-mapping:

 avsender / 

Med servletkartleggingen avgrenser vi den ved navn til a URLmønster som spesifiserer hva HTTP forespørsler vil bli håndtert av den.

4. Hybridkonfigurasjon

Med vedtakelsen av versjonen 3.0 av Servlet APIer, den web.xml filen har blitt valgfri, og vi kan nå bruke Java til å konfigurere DispatcherServlet.

Vi kan registrere en servlet som implementerer en WebApplicationInitializer. Dette tilsvarer XML konfigurasjonen ovenfor:

offentlig klasse MyWebAppInitializer implementerer WebApplicationInitializer {@Override public void onStartup (ServletContext container) {XmlWebApplicationContext context = new XmlWebApplicationContext (); context.setConfigLocation ("/ WEB-INF / spring / dispatcher-config.xml"); ServletRegistration.Dynamic dispatcher = container .addServlet ("dispatcher", ny DispatcherServlet (kontekst)); dispatcher.setLoadOnStartup (1); dispatcher.addMapping ("/"); }}

I dette eksemplet er vi:

  1. Implementering av WebApplicationInitializer grensesnitt
  2. Overstyring av ved oppstart metode lager vi en ny XmlWebApplicationContext konfigurert med samme fil sendt som contextConfigLocation til servletten i XML eksempel
  3. Så lager vi en forekomst av DispatcherServlet med den nye konteksten som vi nettopp instantierte
  4. Og til slutt registrerer vi servletten med en kartlegging URLmønster

Så vi brukte Java å erklære servletten og binde den til en URL-kartlegging men vi holdt konfigurasjonen atskilt XML fil: dispatcher-config.xml.

5. 100% Java Konfigurasjon

Med denne tilnærmingen blir servlet erklært på Java, men vi trenger fortsatt en XML filen for å konfigurere den. Med WebApplicationInitializer du kan oppnå 100% Java konfigurasjon.

La oss se hvordan vi kan omformulere det forrige eksemplet.

Det første vi må gjøre er å lage applikasjonskonteksten for servletten.

Denne gangen vil vi bruke en kommentarbasert kontekst slik at vi kan bruke Java og merknader for konfigurasjon og fjern behovet for XML filer som dispatcher-config.xml:

AnnotationConfigWebApplicationContext context = new AnnotationConfigWebApplicationContext ();

Denne typen kontekst kan deretter konfigureres for å registrere en konfigurasjonsklasse:

context.register (AppConfig.class);

Eller sette en hel pakke som skal skannes for konfigurasjonsklasser:

context.setConfigLocation ("com.example.app.config");

Nå som applikasjonskonteksten vår er opprettet, kan vi legge til en lytter til ServletContext som vil laste sammenhengen:

container.addListener (ny ContextLoaderListener (kontekst));

Neste trinn er å opprette og registrere vår dispatcherservlet:

ServletRegistration.Dynamic dispatcher = container .addServlet ("dispatcher", ny DispatcherServlet (kontekst)); dispatcher.setLoadOnStartup (1); dispatcher.addMapping ("/");

Nå vår WebApplicationInitializer skal se slik ut:

offentlig klasse MyWebAppInitializer implementerer WebApplicationInitializer {@Override public void onStartup (ServletContext container) {AnnotationConfigWebApplicationContext context = new AnnotationConfigWebApplicationContext (); context.setConfigLocation ("com.example.app.config"); container.addListener (ny ContextLoaderListener (kontekst)); ServletRegistration.Dynamic dispatcher = container .addServlet ("dispatcher", ny DispatcherServlet (kontekst)); dispatcher.setLoadOnStartup (1); dispatcher.addMapping ("/"); }}

Java og merknadskonfigurasjon gir mange fordeler. Vanligvis fører det til kortere og mer kortfattet konfigurasjon, og merknader gir mer kontekst til erklæringer, ettersom den er samlokalisert med koden de konfigurerer.

Men dette er ikke alltid en foretrukket eller til og med mulig måte. For eksempel vil noen utviklere foretrekke å holde koden og konfigurasjonen atskilt, eller du må kanskje jobbe med tredjepartskode som du ikke kan endre.

6. Konklusjon

I denne artikkelen dekket vi forskjellige måter å konfigurere en DispatcherServlet i Vår 3.2+ og det er opp til deg å bestemme hvilken du vil bruke basert på dine preferanser. Vår vil imøtekomme din beslutning uansett hva du velger.

Du kan finne kildekoden fra denne artikkelen på Github her og her.


$config[zx-auto] not found$config[zx-overlay] not found