web.xml vs Initializer med Spring

1. Oversigt

I denne artikel dækker vi tre forskellige tilgange til konfiguration af en DispatcherServlet tilgængelig i nyere versioner af Spring Framework:

  1. Vi starter med en XML konfiguration og en web.xml fil
  2. Derefter migrerer vi Servlet-erklæringen fra web.xml fil til Java-konfiguration, men vi lader enhver anden konfiguration være XML
  3. Endelig i det tredje og sidste trin i refactoring har vi et 100% Java-konfigureret projekt

2. Den DispatcherServlet

Et af kernebegreberne i Forår MVC er DispatcherServlet. Forårsdokumentationen definerer det som:

En central afsender til HTTP-anmodningshåndterere / -controllere, f.eks. til web-UI-controllere eller HTTP-baserede fjerntjenesteeksportører. Afsendelse til registrerede håndterere til behandling af en webanmodning, der giver bekvemme faciliteter til kortlægning og undtagelse.

Dybest set DispatcherServlet er hvert indgangssted Forår MVC Ansøgning. Dens formål er at opfange HTTP anmodninger og sende dem til den rigtige komponent, der ved, hvordan man håndterer den.

3. Konfiguration med web.xml

Hvis du beskæftiger dig med arv Forår projekter, det er meget almindeligt at finde XML konfiguration og indtil Forår 3.1 den eneste måde at konfigurere DispatcherServlet var med WEB-INF / web.xml fil. I dette tilfælde kræves der to trin.

Lad os se et eksempel på konfiguration - det første trin er Servlet-erklæringen:

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

Med denne blok af XML vi erklærer en servlet, der:

  1. Hedder “afsender
  2. Er en forekomst af org.springframework.web.servlet.DispatcherServlet
  3. Initialiseres med en parameter med navnet contextConfigLocation som indeholder stien til konfigurationen XML

belastning ved opstart er en heltalværdi, der specificerer rækkefølgen for, at flere servlets skal indlæses. Så hvis du har brug for at erklære mere end en servlet, kan du definere i hvilken rækkefølge de initialiseres. Servlets markeret med lavere heltal indlæses før servlets markeret med højere heltal.

Nu er vores servlet konfigureret. Det andet trin er at erklære en servlet-kortlægning:

 afsender / 

Med servlet-kortlægningen afgrænser vi den med sit navn til a URLmønster der specificerer hvad HTTP anmodninger håndteres af det.

4. Hybridkonfiguration

Med vedtagelsen af ​​version 3.0 af Servlet API'er, det web.xml filen er blevet valgfri, og vi kan nu bruge Java til at konfigurere DispatcherServlet.

Vi kan registrere en servlet, der implementerer en WebApplicationInitializer. Dette svarer til XML konfiguration 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 eksempel er vi:

  1. Implementering af WebApplicationInitializer interface
  2. Tilsidesættelse af onStartup metode opretter vi en ny XmlWebApplicationContext konfigureret med den samme fil sendt som contextConfigLocation til servlet i XML eksempel
  3. Så opretter vi en forekomst af DispatcherServlet med den nye kontekst, som vi netop forøgte
  4. Og endelig registrerer vi servlet med en kortlægning URLmønster

Så vi brugte Java at erklære servleten og binde den til en URL-kortlægning men vi holdt konfigurationen adskilt XML fil: dispatcher-config.xml.

5. 100% Java Konfiguration

Med denne tilgang erklæres vores servlet i Java, men vi har stadig brug for en XML fil for at konfigurere den. Med WebApplicationInitializer du kan opnå en 100% Java konfiguration.

Lad os se, hvordan vi kan omformulere det foregående eksempel.

Den første ting, vi skal gøre, er at oprette applikationskonteksten til servleten.

Denne gang bruger vi en annoteringsbaseret kontekst, så vi kan bruge Java og kommentarer til konfiguration og fjerne behovet for XML filer som dispatcher-config.xml:

AnnotationConfigWebApplicationContext context = ny AnnotationConfigWebApplicationContext ();

Denne type kontekst kan derefter konfigureres til registrering af en konfigurationsklasse:

context.register (AppConfig.class);

Eller indstilling af en hel pakke, der scannes til konfigurationsklasser:

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

Nu hvor vores applikationskontekst er oprettet, kan vi tilføje en lytter til ServletContext der vil indlæse konteksten:

container.addListener (ny ContextLoaderListener (kontekst));

Det næste trin er at oprette og registrere vores dispatcherservlet:

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

Nu vores WebApplicationInitializer skal se sådan ud:

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 annoteringskonfiguration giver mange fordele. Normalt fører det til kortere og mere kortfattet konfiguration, og annoteringer giver mere kontekst til erklæringer, da den er placeret sammen med den kode, de konfigurerer.

Men dette er ikke altid en foretrukken eller endog mulig måde. For eksempel foretrækker nogle udviklere at holde deres kode og konfiguration adskilt, eller du skal muligvis arbejde med tredjepartskode, som du ikke kan ændre.

6. Konklusion

I denne artikel dækkede vi forskellige måder at konfigurere en DispatcherServlet i Forår 3.2+ og det er op til dig at beslutte, hvilken der skal bruges ud fra dine præferencer. Forår vil imødekomme din beslutning, uanset hvad du vælger.

Du kan finde kildekoden fra denne artikel på Github her og her.


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