Secondo gli autori sarebbe meglio non usare alcun IDE e scriversi tutto a mano. Potrebbero aver ragione, ma é una seccatura immane. Uso perciò Netbeans per semplificarmi la vita.
Creo un nuovo progetto, una Web Application nella categoria Java Web, che chiamo HeadFirstWeb. Come server uso Tomcat 6 e faccio riferimento a Java EE 5.
Nel progetto mi creo una nuova servlet, la cui classe ha nome s01, che metto nel package hf. La servlet ha nome ASimpleServlet e pattern URL /servlet01, confermiamo e andiamo a vedere il codice generato.
web.xml
Il file si trova nel folder WEB-INF e contiene queste informazioni:
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<servlet>
<servlet-name>ASimpleServlet</servlet-name>
<servlet-class>hf.s01</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ASimpleServlet</servlet-name>
<url-pattern>/servlet01</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>30</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>
Ci interessano le sezioni relative alle servlet. Il primo blocco definisce la correlazione tra il nome della servlet, ASimpleServlet, e la sua classe Java di riferimento, hf.s01; nel blocco servlet-mapping vediamo la correlazione tra il nome della servlet e l'URL utilizzata per accederla.
In pratica il nome della servlet fa da tramite tra il nome della classe Java che la implementa e l'indirizzo con cui é possibile richiamarla.
s01.java
Il file si trova nella sezione Source Packages, nel package hf.
Modifichiamo solo leggermente il codice proposto. L'intestazione del file resta tale e quale:
package hf;
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
La classe viene definita come una estensione di HttpServlet:
public class s01 extends HttpServlet {
Quello che cambiamo é il metodo processRequest() che viene utilizzato per processare sia POST che GET. In realtà a noi, a questo punto, interesserebbe solo considerare la GET, quindi potremmo semplificare il codice, eliminando la gestione per la POST e spostando il codice definito in processRequest() nel corpo di doGet(). Ma non ci pare un impresa particolarmente utile, e quindi non cambiamo questo codice:
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
processRequest(request, response);
}
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
processRequest(request, response);
}
Nella processRequest() rendiamo attivo il codice che genera una response e facciamo in modo che venga visualizzato il timestamp corrente:
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
try {
out.println("<html>");
out.println("<head>");
out.println("<title>Servlet s01</title>");
out.println("</head>");
out.println("<body>");
out.println("<h1>Servlet @ " + new java.util.Date() + "</h1>");
out.println("</body>");
out.println("</html>");
} finally {
out.close();
}
}
Notiamo che settiamo il tipo di contenuto della response a testo html codificato in UTF-8, e che scriviamo il codice HTML nella response approfittando dell'oggetto PrintWriter che la response ci mette a disposizione.
Notiamo anche che la scrittura sulla response é racchiusa in un blocco try a cui corrisponde un finally in cui chiudiamo il writer. Così anche in caso di eccezioni durante la scrittura chiudiamo correttamente il writer.
Facciamo una build del progetto e otteniamo un .war (Web Archive) che contiene la nostra piccola web application. Ne facciamo un deploy per la nostra installazione Tomcat e possiamo vedere la nostra servlet in azione.
C'é una varietà di modi per eseguire l'installazione di un war su Tomcat. Di solito io faccio così:
- startup di Tomcat (nel mio caso gli ho riservato la porta 8084)
- accesso di Tomcat via browser (http://localhost:8084/)
- accesso del Tomcat Web Application Manager (http://localhost:8084/manager/html). Nota che un utente Tomcat deve avere i privilegi di admin per poter accedere a questa pagina, vedi il file conf/tomcat-users.xml nell'installazione di Tomcat.
- verso il fondo della pagina c'é la sezione Deploy, sottosezione WAR file to deploy. Basta selezionare il nostro file war, cliccare sul bottone Deploy e il gioco é fatto.
A questo punto per accedere la servlet dovrebbe bastare specificare questo URL:
http://localhost:8084/HeadFirstWeb/servlet01
Il difetto principale di questo approccio, ci fanno notare gli autori del libro, sta nella innaturalità dell'inserimento di codice HTML all'interno di codice Java. Generare una pagina complessa, e mantenerla, diventa un compito veramente spiacevole.
Fortunatamente si può fare il contrario, ovvero inserire codice Java all'interno di HTML, ricorrendo a JSP.
Torniamo al nostro progetto HeadFirstWeb, notiamo che Netbeans ha generato anche un index.jsp nella sezione WebPages. Andiamo a modificarla leggermente, per inserire il codice Java che ci interessa (la generazione del timestamp) e, già che ci siamo, un link alla servlet. Il corpo della pagina diventa questo:
<body>
<h1>Hello World!</h1>
JSP @ <%= new java.util.Date() %>
<br />
<a href="servlet01" target="_blank">Servlet</a>
</body>
Compiliamo, rimuoviamo il vecchio war da Tomcat e installiamo il nuovo e ora, specificando questa URL:
http://localhost:8084/HeadFirstWeb/
Dovremmo vedere la nostra pagina JSP, con link alla servlet che abbiamo creato in precedenza.
Nessun commento:
Posta un commento