Per pubblicare (deploy) una qualsiasi applicazione su Tomcat, è necessario definire prima un contesto, in modo implicito o esplicito. Ogni contesto Tomcat rappresenta una web appllication, l'associazione è uno a uno.

Ci sono molti modi per definire un contesto in modo esplicito:

• Creare un file XML nella directory Tomcat conf/Catalina/localhost
• Aggiungere un elemento context al file Tomcat conf/server.xml

22 agosto 2017

Context path e web application context negli URL Tomcat

Cos'è un "Tomcat context"?

Per pubblicare (deploy) una qualsiasi applicazione su Tomcat, è necessario definire prima un contesto, in modo implicito o esplicito. Ogni contesto Tomcat rappresenta una web application context, l'associazione è uno a uno. Ogni server Tomcat può avere in esecuzioni più contesti, cioè applicazioni, e uno (e solo uno) di queste può essere configurato come quello di default. Per accedervi basta non mettere il nome del contesto nell' URL. Ci sono molti modi per definire una applicazione come quella di default. Uno di questi è usare ROOT.war come nome del file di deploy. Qui un link sull'argomento.

Ci sono molti modi per definire un contesto in modo esplicito:

Creare un file XML nella directory Tomcat conf/Catalina/localhost

Aggiungere un elemento context al file Tomcat conf/server.xml

1° modo esplicito : conf/Catalina/localhost

Se si sceglie la prima opzione la scelta del nome del file XML è importante, perchè da esso deriverà la costruzione del context path negli URL Tomcat. Per esempio un file di contesto chiamato negozio.xml determinerà un context path per l'applicazione pari a negozio e gli URL di accesso alla web app avranno questo aspetto:

http://localhost:8080/negozio/nomeRisorsaWebApp

Questo di seguito è un esempio di context XML file. Deve avere come elemento root "Context", che di solito rimande anche l'unico elemento in tutto il file. L'unico attributo obbligatorio è docBase, ad indicare il path name completo dell' applicazione web su filesystem.

Reloadable è un attributo opzionale, il cui valore di default se non indicato è false. Quando è true, Tomcat monitora ogni modifica alle classi Java o allle altre risorse che compongono l' applicazione web. Nel momento in cui rileva una modifica, automaticamente Tomcat ricarica (reload) l'applicazione web. E' consigliabile tenere il valore false sui sistemi di produzione, ed usare il reload automatico solo negli ambienti di test.

Quando si aggiunge un nuovo file context, Tomcat automaticamente effettua il deploy dell'applicazione (load). Quando il file viene cancellato, automaticamente Tomcat scarica l'applicazione (unload).

2° modo esplicito : conf/server.xml

Un altro sistema è quello di andare ad integrare il file conf/server.xml con un nuovo elemento "Context", all'interno dell' elemento "Host". Mentre con il primo metodo era il nome del file a definire quello del contesto, in questo secondo modo il nome viene definito scrivendolo in modo esplicito attraverso l' atttributo path:

Piccolo appunto sull' attributo "appBase" che compare in questo caso. Si tratta dell' Application Base Directory dell' host virtuale. E' il pathname della directory che di base contiene le applicazioni web da caricare (deploy) sull' host virtuale definito dall 'elemento "Host". Può essere un path assoluto oppure relativo alla directory $CATALINA_BASE.

Metodo esplicito, quale dei due?

Il 1°, almeno in ambiente di produzione. Tutte le modifiche apportate usando il 2° metodo richiedono il restart di Tomcat. Al massimo il 2° metodo può tornare comodo quando si testano in locale varie applicazioni, in modo da avere a che fare con un file solo di configurazione e non con n diversi file XML.

1° (e unico) metodo implicito

Consiste nel copiare il file WAR, o l'intera applicazione, nella cartella webapps di Tomcat.

Documentazione Apache

Servlet URL patterns

L'interfaccia servlet definisce un contratto tra una servlet e il servlet container che le permette di funzionare (Tomcat in questo caso). Il contratto prevede che il container carichi la classe servlet in memoria nel momento in cui vengono chiamati specifici metodi HTTP indirizzati all' istanza della servlet.

Può esserci una sola instanza per ogni servlet type in una applicazione, condivisa tra gli utenti web. Di conseguenza è meglio evitare variabili di classe, a meno che siano siano read-only o membri del package java.util.concurrent.atomic.

La servlet chiamata in causa viene determinata in base all' URL usato per le chiamate. Infatti ogni container può avere installate più applicazioni servlet-based, ognuna associata ad un particolare path (metodi espliciti/impliciti trattai prima). Quindi abbiamo un primo livello nell' URL, che determina l'applicazione (negozio), le porzioni di URL successive identificano quale servlet coinvolgere all'interno dell'applicazione negozio.

Quindi una servlet come quella sotto, caricata (deploy) in un file di nome negozio.war nell' host virtuale "localhost" verrà chiamata con un url simile a http://localhost:8080/negozio/fruttivendolo":

import javax.serlvet.annotation.WebServlet; @WebSerlvet(name="Il MioNegozioDiFrutta" urlPatterns = { "/fruttivendolo" }) public class MioNegozioDiFruttaServlet implements Servlet { .... }

La mappatura tra servlet e path può essere fatta come nel caso sopra con una annotazione WebServlet, oppure usando il "deployment descriptor", vale a dire il file web.xml (che deve avere questo nome) posizionato nella directory WEB-INF del solito file war. Ci sono indubbi vantaggi nell' uso del file web.xml: non richiede una ricompilazione per introdurre modifiche ed è possibile specificare elementi come load-on-startup, cosa che con l'annotazione non è possibile. A prescindere da questo, nel caso sia presente una definizione per una servlet sia nel web.xml sia sotto forma di annotazione, il file web.xml vince e sovrascrive i valori.

Servlet Context

Il servlet container mette a disposizione di ogni servlet l'accesso ad una instanza del Servlet Context. . La servlet può usare questo oggetto per comunicare con il servlet container (Tomcat in questo caso), per scrivere nei file di log per esempio.

Esiste una istanza ServletContext per ogni web application per ogni JVM. Scritto così si capisce poco ... Per web application si intende un set di servlet ed altri contenuti (immagini, file css, html, JSP, file .ini ...) installati sotto un particolare subset del server Tomcat URL namespace. Insomma una web application è un .WAR caricato.

Interface ServletContext