Configuratieparameters voor context en servlet

1. Overzicht

Servlets zijn gewone Java-klassen die in een servletcontainer worden uitgevoerd.

HTTP-servlets (een specifiek type servlet) zijn eersteklas burgers in Java-webapplicaties. De API van HTTP-servlets is gericht op het afhandelen van HTTP-verzoeken via de typische verzoek-verwerking-antwoordcyclus, geïmplementeerd in client-server-protocollen.

Bovendien kunnen servlets de interactie tussen een client (meestal een webbrowser) en de server besturen met behulp van sleutelwaardeparen in de vorm van verzoek- / antwoordparameters.

Deze parameters kunnen worden geïnitialiseerd en gebonden aan een toepassingsbreed bereik (contextparameters) en een servlet-specifiek bereik (servletparameters).

In deze tutorial leren we hoe context- en servlet-initialisatieparameters te definiëren en openen.

2. Initialiseren van servletparameters

We kunnen servletparameters definiëren en initialiseren met behulp van annotaties en de standaard deployment descriptor - de "Web.xml" het dossier. Het is vermeldenswaard dat deze twee opties elkaar niet uitsluiten.

Laten we elk van deze opties grondig onderzoeken.

2.1. Annotaties gebruiken

Door servletparameters te initialiseren met annotaties, kunnen we de configuratie en de broncode op dezelfde plaats houden.

In dit gedeelte laten we zien hoe u met behulp van annotaties initialisatieparameters kunt definiëren en openen die aan een specifieke servlet zijn gebonden.

Om dit te doen, zullen we een naïef implementeren UserServlet klasse die gebruikersgegevens verzamelt via een gewoon HTML-formulier.

Laten we eerst eens kijken naar het JSP-bestand dat ons formulier weergeeft:

   Context en initialisatie Servlet-parameters 

Vul dan onderstaand formulier in:

Naam:E-mailadres:

Merk op dat we de formulieren hebben gecodeerd actie attribuut met behulp van de EL (de Expression Language). Hierdoor kan het altijd naar de "/ UserServlet" pad, ongeacht de locatie van de toepassingsbestanden op de server.

De "$ {PageContext.request.contextPath}" uitdrukking stelt een dynamische URL in voor het formulier, die altijd relatief is aan het contextpad van de toepassing.

Dit is onze eerste servlet-implementatie:

@WebServlet (name = "UserServlet", urlPatterns = {"/ userServlet"}, initParams = {@WebInitParam (name = "name", value = "Niet opgegeven"), @WebInitParam (name = "email", value = " Niet verstrekt ")})) openbare klasse UserServlet breidt HttpServlet uit {// ... @Override beschermde ongeldige doPost (HttpServletRequest-verzoek, HttpServletResponse-antwoord) gooit ServletException, IOException {processRequest (verzoek, antwoord); forwardRequest (verzoek, antwoord, "/WEB-INF/jsp/result.jsp"); } beschermde ongeldige processRequest (verzoek HttpServletRequest, antwoord HttpServletResponse) gooit ServletException, IOException {request.setAttribute ("naam", getRequestParameter (verzoek, "naam")); request.setAttribute ("e-mail", getRequestParameter (verzoek, "e-mail")); } beschermde ongeldige forwardRequest (HttpServletRequest-verzoek, HttpServletResponse-antwoord, String-pad) gooit ServletException, IOException {request.getRequestDispatcher (pad) .forward (verzoek, antwoord); } beschermde String getRequestParameter (HttpServletRequest-verzoek, String-naam) {Stringparameter = request.getParameter (naam); terugkeer! param.isEmpty ()? param: getInitParameter (naam); }} 

In dit geval hebben we twee initialisatieparameters voor de servlet gedefinieerd, naam en e-mail, door gebruik makend van initParams en de @WebInitParam annotaties.

Houd er rekening mee dat we HttpServletRequest's hebben gebruikt getParameter () methode om de gegevens uit het HTML-formulier op te halen, en de getInitParameter () methode om toegang te krijgen tot de initialisatieparameters van de servlet.

De getRequestParameter () methode controleert of het naam en e-mail verzoekparameters zijn lege tekenreeksen.

Als het lege strings zijn, krijgen ze de standaardwaarden van de overeenkomende initialisatieparameters toegewezen.

De doPost () methode haalt eerst de naam en het e-mailadres op die de gebruiker in het HTML-formulier heeft ingevoerd (indien aanwezig). Vervolgens verwerkt het de verzoekparameters en stuurt het verzoek door naar een "Result.jsp" het dossier:

    Gebruikersgegevens 

gebruikers informatie

Naam: $ {naam}

E-mailadres: $ {email}

Als we onze voorbeeldwebtoepassing implementeren op een applicatieserver, zoals Apache Tomcat, Oracle GlassFish of JBoss WidlFly, en deze uitvoeren, moet deze eerst de HTML-formulierpagina weergeven.

Zodra de gebruiker het naam en e-mail velden en het formulier heeft verzonden, zal het de gegevens uitvoeren:

Gebruikersinformatie Naam: de gebruikersnaam. E-mail: het e-mailadres van de gebruiker 

Als het formulier gewoon leeg is, worden de initialisatieparameters van de servlet weergegeven:

Gebruikersinformatie Naam: niet opgegeven E-mail: niet opgegeven 

In dit voorbeeld hebben we laten zien hoe u servlet-initialisatieparameters kunt definiëren met behulp van annotaties, en hoe u deze kunt openen met de getInitParameter () methode.

2.2. Met behulp van de Standard Deployment Descriptor

Deze benadering verschilt van degene die annotaties gebruikt, omdat het ons in staat stelt om configuratie en broncode van elkaar geïsoleerd te houden.

Om te laten zien hoe u initialisatie-servletparameters kunt definiëren met de "Web.xml" bestand, laten we eerst het initParam en @WebInitParam annotaties van de UserServlet klasse:

@WebServlet (name = "UserServlet", urlPatterns = {"/ userServlet"}) openbare klasse UserServlet breidt HttpServlet uit {...} 

Laten we vervolgens de initialisatieparameters van de servlet definiëren in het "Web.xml" het dossier:

   UserServlet UserServlet naam Niet opgegeven e-mail Niet opgegeven 

Zoals hierboven getoond, definieert u servlet-initialisatieparameters met behulp van de "Web.xml" bestand komt gewoon neer op het gebruik van de , en tags.

Bovendien is het mogelijk om zoveel servletparameters te definiëren als nodig is, zolang we ons aan de bovenstaande standaardstructuur houden.

Wanneer we de applicatie opnieuw op de server implementeren en opnieuw uitvoeren, zou deze zich hetzelfde moeten gedragen als de versie die annotaties gebruikt.

3. Initialiseren van contextparameters

Soms moeten we een aantal onveranderlijke gegevens definiëren die wereldwijd moeten worden gedeeld en toegankelijk via een webtoepassing.

Vanwege de wereldwijde aard van de gegevens, zouden we dat moeten doen gebruik applicatie-brede context-initialisatieparameters voor het opslaan van de gegevens, in plaats van toevlucht te nemen tot de tegenhangers van de servlet.

Hoewel het niet mogelijk is om contextinitialisatieparameters te definiëren met behulp van annotaties, kunnen we dit doen in het "Web.xml" het dossier.

Stel dat we een aantal algemene standaardwaarden willen leveren voor het land en de provincie waar onze applicatie wordt uitgevoerd.

We kunnen dit bereiken met een aantal contextparameters.

Laten we het "Web.xml" dienovereenkomstig in:

  provincie Mendoza land Argentinië 

Deze keer hebben we de , , en tags om de provincie en land contextparameters.

Natuurlijk moeten we de UserServlet class zodat het deze parameters kan ophalen en doorgeven aan de resultatenpagina.

Hier zijn de relevante secties van de servlet:

@WebServlet (name = "UserServlet", urlPatterns = {"/ userServlet"}) public class UserServlet breidt HttpServlet uit {// ... protected void processRequest (HttpServletRequest-verzoek, HttpServletResponse-antwoord) gooit ServletException, IOException {request.setAttception ", getRequestParameter (verzoek," naam ")); request.setAttribute ("e-mail", getRequestParameter (verzoek, "e-mail")); request.setAttribute ("provincie", getContextParameter ("provincie")); request.setAttribute ("land", getContextParameter ("land")); } beschermde String getContextParameter (String naam) {- retourneer getServletContext (). getInitParameter (naam); }} 

Let op de getContextParameter () methode implementatie, die haalt eerst de servlet-context door getServletContext (), en haalt vervolgens de contextparameter op met de getInitParameter () methode.

Vervolgens moeten we het "Result.jsp" bestand zodat het de contextparameters kan weergeven samen met de servlet-specifieke parameters:

Naam: $ {naam}

E-mailadres: $ {email}

Provincie: $ {provincie}

Land: $ {country}

Ten slotte kunnen we de applicatie opnieuw implementeren en opnieuw uitvoeren.

Als de gebruiker het HTML-formulier vult met een naam en een e-mail, worden deze gegevens samen met de contextparameters weergegeven:

Gebruikersinformatie Naam: de gebruikersnaam E-mail: het e-mailadres van de gebruiker Provincie: Mendoza Land: Argentinië 

Anders zou het de servlet- en contextinitialisatieparameters uitvoeren:

Gebruikersinformatie Naam: niet opgegeven E-mail: niet opgegeven Provincie: Mendoza Land: Argentinië 

Hoewel het voorbeeld gekunsteld is, is het te zien hoe contextinitialisatieparameters te gebruiken om onveranderlijke globale gegevens op te slaan.

Omdat de gegevens zijn gebonden aan de toepassingscontext, in plaats van aan een bepaalde servlet, kunnen we ze openen vanaf een of meerdere servlets, met behulp van de getServletContext () en getInitParameter () methoden.

4. Conclusie

In dit artikel, we hebben de belangrijkste concepten van context- en servlet-initialisatieparameters geleerd en hoe we ze kunnen definiëren en openen met behulp van annotaties en de "Web.xml" het dossier.

Al geruime tijd is er in Java een sterke tendens om XML-configuratiebestanden te verwijderen en waar mogelijk naar annotaties te migreren.

CDI, Spring, Hibernate, om er maar een paar te noemen, zijn hier sprekende voorbeelden van.

Desalniettemin is er niets inherent mis met het gebruik van de "Web.xml" bestand voor het definiëren van context- en servlet-initialisatieparameters.

Ook al is de Servlet-API in vrij snel tempo naar deze tendens geëvolueerd, we moeten nog steeds de implementatiedescriptor gebruiken voor het definiëren van parameters voor contextinitialisatie.

Zoals gewoonlijk zijn alle codevoorbeelden die in dit artikel worden getoond, beschikbaar op GitHub.


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