7.1 Schema generale di web.xml

Il file web.xml memorizza le informazioni sulla configurazione dell'applicazione. Non è una parte obbligatoria di esso, ma è molto utilizzato per configurare un'applicazione web.

Questo file deve trovarsi nella cartella WEB-INF . Quando Tomcat si avvia, ne legge il contenuto e utilizza la configurazione in esso contenuta. Se il file contiene errori, anche Tomcat visualizza un errore.

Esempio web.xml:



<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
  http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd" version="4.0">
  
  <servlet>
       <servlet-name>HelloWorld</servlet-name>
       <servlet-class>HelloServlet</servlet-class>
   </servlet>
    
  <servlet-mapping>
      <servlet-name>HelloWorld</servlet-name>
      <url-pattern>/welcome</url-pattern>
  </servlet-mapping>
 
  <welcome-file-list>
      <welcome-file>index.html</welcome-file>
  </welcome-file-list>
  
</web-app>

"HelloWorld"La mappatura del nome servlet e della classe servlet è scritta qui in verde"HelloServlet" . La mappatura del nome del servlet e del blocco dell'URL è scritta in blu"HelloWorld""http://localhost/welcome" . Pertanto, qui si dice che quando si accede al percorso /welcome, è necessario chiamare il servlet HelloServlet.class.

Il colore rosso indica il file che deve essere fornito su richiesta http://localhost/: questa è la cosiddetta pagina di benvenuto . Se l'utente semplicemente digita nel browser il nome corrispondente alla radice della nostra applicazione web, allora il contenuto del file index.html.

7.2 servlet, mappatura servlet

Un servlet può servire richieste a diversi URL, quindi in web-xml, il servlet e la sua mappatura agli URL sono scritti separatamente. Innanzitutto, descriviamo i servlet, assegnando a ciascuno un nome di stringa univoco, quindi specifichiamo come ogni servlet si associa a quale URL.

Esempio web.xml:



<web-app>
  
  <servlet>
    <servlet-name>remoting</servlet-name>
    <servlet-class>com.codegym.RemotingServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>
 
  <servlet-mapping>
    <servlet-name>remoting</servlet-name>
    <url-pattern>/remoting/*</url-pattern>
  </servlet-mapping>
 
  <servlet>
    <servlet-name>restapi</servlet-name>
    <servlet-class>com.codegym.RestApiServlet</servlet-class>
    <load-on-startup>2</load-on-startup>
  </servlet>
 
  <servlet-mapping>
    <servlet-name>restapi</servlet-name>
    <url-pattern>/api/*</url-pattern>
  </servlet-mapping>  
 
</web-app>

In questo esempio, vengono dichiarati due servlet e ciascuno è mappato a un diverso modello di URL. Il servlet RemotingServletserve tutte le richieste che vanno a/remoting/* . Il servlet RestApiServletserve tutte le richieste che vanno a/api/* . I servlet hanno anche l'ordine dal caricamento - il parametro load-on-startup.

7.3 Opzioni servlet

Con l'aiuto di web.xml, i parametri possono essere passati al servlet durante la sua inizializzazione, saranno disponibili attraverso l'interfaccia ServletConfig. Puoi anche impostare i parametri per l'intera applicazione web, saranno disponibili tramite il file ServletContext.

Esempio web.xml:



<web-app>
  <context-param>
     <description>Server production mode</description>
     <param-name>productionMode</param-name>
     <param-value>false</param-value>
  </context-param>
 
  <context-param>
     <param-name>appPropertiesConfig</param-name>
     <param-value>
        classpath:local-app.properties
        classpath:web-app.properties
     </param-value>
  </context-param>
 
  <servlet>
     <servlet-name>mainservlet</servlet-name>
     <servlet-class>com.codegym.ApplicationServlet</servlet-class>
     <init-param>
        <param-name>application</param-name>
        <param-value>com.codegym.App</param-value>
     </init-param>
     <init-param>
        <param-name>widgetset</param-name>
        <param-value>com.codegym.WidgetSet</param-value>
     </init-param>
     <init-param>
        <param-name>ui</param-name>
        <param-value>com.codegym.AppUI</param-value>
     </init-param>
  </servlet>
</web-app>

Il codice evidenziato in verde è dove impostiamo i parametri perServletContext . Ce ne sono due:

  • productionModecon valore falso
  • appPropertiesConfigcon un array di due stringhe:
    • classpath:local-app.properties
    • classpath:web-app.properties

In blu sono indicati i parametri per la servletApplicationServlet , saranno a sua disposizione attraverso ServletConfig:

  • applicationcon valore com.codegym.App
  • widgetsetcon valore com.codegym.WidgetSet
  • uicon valore com.codegym.AppUI

7.4 filtro, mappatura dei filtri

L'applicazione web può anche contenere file utility servlets - filters. Svolgono varie attività di servizio: reindirizzare le chiamate, controllare l'autorizzazione, ecc.

Esempio web.xml:



<web-app>
 
  <servlet>
      <servlet-name>remoting</servlet-name>
      <servlet-class>RemotingServlet</servlet-class>
      <load-on-startup>1</load-on-startup>
  </servlet>
 
  <servlet-mapping>
      <servlet-name>remoting </servlet-name>
      <url-pattern>/remoting/*</url-pattern>
  </servlet-mapping>
 
  <filter>
      <filter-name>total_filter</filter-name>
      <filter-class>com.javrush.TotalFilter</filter-class>
  </filter>
 
  <filter-mapping>
      <filter-name>total_filter</filter-name>
      <url-pattern>/*</url-pattern>
  </filter-mapping>
 
</web-app>

Prima che la richiesta raggiunga il servlet RemotingServlet, verrà elaborata dal filtro TotalFiler. Questo filtro è configurato per intercettare tutte le richieste che arrivano alla nostra applicazione web. Ciò è chiaramente suggerito dal modello di URL a cui è mappato: /*.

Leggerai di più su servlet e filtri nelle lezioni seguenti.