I Prerequisiti 1. Conoscenza elementare di java. Breve Tutorial su J2EE Per avere un introduzione a java si può consultare il libro Thinking in Java 1. Conoscenza del linguaggio html. II Introduzione La piattaforma J2EE permette di costruire applicazioni seguendo il principio MVC (model view controller). Tale modello si propone di separare la vista dei dati, dai dati stessi e dal controllo sui dati. Le applicazioni J2EE vengono eseguite da dei software detti application server che offrano alcune funzionalità già implementate. In questo documento trascuriamo alcuni aspetti delle funzionalità offerte da un application server j2ee e ci concentriamo sui passi fondamentali per lo sviluppo di una web application in ambiente J2EE. In particolare ci concentreremmo sui passi per la creazione della parte web dell'applicazione. II.1 Struttura dell'applicazione Consideriamo una generica applicazione che deve manipolare dei dati presenti su di un Data Base. Lo schema dei server con cui interagiremmo è il seguente: Il motivo per cui nella figura sono stati rappresentati distinti il web server, il servlet engine, ed il container ejb è che essi possono fisicamente trovarsi su macchine diverse collegate in rete. Noi per ora li considereremmo non solo sulla installati sulla stessa macchina ma facenti parte dello stesso software applicativo. la sequenza logica del funzionamento è il seguente: 1
1) L'utente si connette al web server dell'application server. 2) Manda un richiesta POST o GET 1 al web server. 3) Il web server chiama la servlet che esegue la richiesta. 4) la servlet carica l'ejb e ne esegue i metodi necessari. 5) l'ejb si connette al database agisce come richiesto sui dati. 6) la servlet crea la pagina html di risposta alla richiesta. 7) il web server rimanda la pagina al browser dell'utente. Nel seguito di questo documento analizzeremmo una applicazione di esempio minimale e descriveremmo i passi per creare l'applicazione. III Architettura software dell'applicazione di esempio L'applicazione è composta da: 1. Un EJB di cui non analizzeremmo in profondità il codice ma vedremmo solamente come interfacciarsi con esso. 2. Una servlet con alcune helper class (Classi di utilità) L'architettura è rappresentata nella seguente figura: Analizziamo l'architettura rappresentata in fugura: 1 I metodi post e get sono standard definiti dalla w3c. Ref: http://www.w3.org/protocols/rfc2616/rfc2616-sec9.html 2
La richiesta dell'utente arriva al web server: caso in cui la richiesta è di una pagina statica: il web server carica la pagina statica e la invia all'utente. Caso in cui la viene richiesta una pagina dinamica: il web server chiama la servlet la servlet chiede al bean di effettuare le operazioni richieste sui dati la servlet tramite le API 2 Jakarta-Velocity 3 prende dei template html e ne valorizza i campi. La servlet restituisce le pagine così create al web server il web server invia i dati all'utente IV Class Diagram dell'applicazione Il class diagram illustra come viene organizzata l'applicazione in termini di classi ed i legami tra le le varie classi dell'applicazione. Le classi normalmente vengono organizzate in package 4 che assolvono a due funzioni: 1. raggruppano logicamente le classi 2. evitano che vi siano dei conflitti nei nomi delle classi Un class diagram normalmente è rappresentato utilizzando gli standard UML. IV.1 Definizione dei package delle classi a Classi di utilità Comuni ad EJB e Servlet Come abbiamo detto avremmo delle classi che vengono utilizzate sia dagli EJB che dalle servlet. dato che concettualmente gli ejb e le servlet possono girare in ambienti distinti è opportuno raggruppare le classi di utilità comuni in modo da poterle facilmente includerle sia nella distribuzione degli EJB che in quella delle servlet se vuole sfruttare questa opportunità. Inoltre quando si usa una classe all'interno di un altra la si deve importare l'aver raggruppato le classi di utilità comuni ad EJB e SERVLET in un unico package permette di importarle facilmente senza fare errori basta inserire con un solo import. Nelle classi di utilità comuni includeremmo: 1. I value object: Si usa chiamare Value Object una classe che è adibita a contenere dei dati, tale classe fornisce i metodi per inserire i dati all'interno di essa. Tali metodi sono deputati a 2 API, Application Programming Interface, Librerie di Classi che forniscono delle utilità 3La documentazione delle API Jakarta-Velocity è reperibile all'indirizzo: http://jakarta.apache.org/velocity/user-guide.html 4Ref: http://java.sun.com/docs/books/tutorial/ e 'Thinking in java' 3
controllare che il dato inserito sia consistente con le regole che devono essere applicate al dato. Es: il dato nome è una stringa composta da soli caratteri alfabetici maiuscoli e minuscoli e non può avere lungezza superiore a 24 caratteri. Il metodo di inserimento (per convenzione si chiama setnomevariabile(tipo_variabile variabile)) setnome(string nome) si preoccupa di verificare che la stringa passata in input sia di 24 caratteri alfabetici. 2. Una classe contenente le costanti 3. Una classe che contiene le eccezioni 4 del nostro applicativo. Il package in cui saranno messe queste classi è (questo significa che nel codice delle classi la prima istruzione è: package com.apat.ccon.common): com.apat.ccon.common b Classi degli EJB Un enterprise java bean è composto come minimo da una classe e due interfacce: La classe che contiene il codice dell'ejb vero e propri. La HOME Interface, che contiene i metodi per creare, distruggere etc. L'ejb. La REMOTE Interface, che è l'interfaccia usata dal client per accedere ai metodi dell'ejb. Le servlet utilizzeranno solo le interfacce HOME e REMOTE dell'ejb. Per convenzione chiameremmo le classi secondo la seguente convenzione: NomeBeanSLEjb è l'ejb vero e proprio NomeBeanSL è la REMOTE interface NomeBeanSLHome è la HOME Interface Insieme a queste classi metteremo una classe DAO (Database Access Object) che si occupera di interfacciarsi con il database. Il package in cui saranno messe queste classi è (questo significa che nel codice delle classi la prima istruzione è: package com.apat.ccon.ejb): com.apat.ccon.ejb c Classi delle servlets In questo gruppo vi sono tutte le servlet chiamate dall'interfaccia utente più le due seguenti classi: La Classe Proxy: Questa classe si occupa di prendere la home interface dell'ejb, di creare tramite la HOME interface le REMOTE interface dell'ejb, e di chiamare i metodi sull EJB. La Classe Facade: 4
Crea un istanza Static del Proxy in modo da non dover predere la remote per ogni connessione ma di farlo una sola volta ed espone i metodi del proxy alle servlet. Il package in cui saranno messe queste classi è (questo significa che nel codice delle classi la prima istruzione è: package com.apat.ccon.web): com.apat.ccon.web nella nostra applicazione è presente un super classe ulteriore di utilità per le servlet. Le servlet che vorranno usufruire dei settaggi standard e dei metodi di utilità implementati in questa classe dovranno estenderla. La Classe CCOONServlet: Questa è una classe di utilità include i metodi comiuni a tutte le servlet come i metodi di inizializzazione e di gestione delle eccezioni. V Breve Introduzione Alle Applicazioni J2EE Una applicazione J2EE è una applicazione sviluppata seguendo gli standard di questa tecnologia, il codice sviluppato non è auto consistente ma per essere utilizzato deve essere inserito in un application server che risponde alle specifiche J2EE. Tale server si occupa di caricare l'applicazione e la rende utilizzabile. V.1 L'archivio ear Una applicazione J2EE deve essere contenuta in un archivio con estensione.ear. All'interno di questo file vi è un archivio con estensione.jar, un archivio con estensione.war, una directory META-INF contenente il file application.xml come descritto nella tabella seguente. Contenuto dell'archivio.ear path/ nome file path/ nome file path/ nome file descrizione Archivio.jar Archivio contenente l'ejb Archivio.war META-INF Archivio contenente la Web Application Derictory contenente il descrittore dell'applicazione application.xml File XML descrittore dell'applicazione. Tale file è usato dall'application server per sapere di cosa è composta l'applicazione 5
Esempio di file descrittore: <?xml version="1.0" encoding="iso8859_1"?> <!DOCTYPE application PUBLIC '-//Sun Microsystems, Inc.//DTD J2EE Application 1.2//EN' 'http://java.sun.com/j2ee/dtds/application_1_2.dtd'> <application> <display-name>ccoon</display-name> <description>ejb del Sistema Centro di Coordinamento Nazionale</description> <module> <ejb>ccoon.jar</ejb> </module> <module> <web> <web-uri>ccoon.war</web-uri> <context-root>ccoon</context-root> </web> </module> </application> V.2 L'archivio jar L'archivio con estenzione.jar contiene tutte le informazioni necessarie all'application server per 'creare' l'ejb in esso sono compresi i seguenti file: 1. le classi java che compongono gli ejb contenuti nell'archivio, quindi tutte le loro remote ed home interface, tutti gli ejb veri e propri e tutte le loro helper class (DAO e quantaltro) 2. un descrittore ejb-jar.xml posto nella directory META-INF che descrive all'application server gli ejb contenuti nell'archivio 3. un decrittore opzionale che imposta le opzioni specifiche dell'application server Esempio di un descrittore: <?xml version="1.0"?> <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'> <ejb-jar> <description>ejb del sistema Centro di coordinamento nazionale</description> <display-name>ccoon System EJB</display-name> <enterprise-beans> <session> <ejb-name>ccoonsl</ejb-name> 6
<home>com.apat.ccoon.ejb.ccoonslhome</home> <remote>com.apat.ccoon.ejb.ccoonsl</remote> <ejb-class>com.apat.ccoon.ejb.ccoonslejb</ejb-class> <session-type>stateless</session-type> <transaction-type>container</transaction-type> </session> </enterprise-beans> <assembly-descriptor> <container-transaction> <method> <ejb-name>ccoonsl</ejb-name> <method-name>*</method-name> </method> <trans-attribute>required</trans-attribute> </container-transaction> </assembly-descriptor> </ejb-jar> V.3 L'archivio war L'archivio con estenzione.war contiene tutte le informazioni necessarie all'application server per 'creare' la Web Application in esso sono compresi i seguenti file: 1. tutte le pagine statiche html, i template e le classi degli applet usati nella Web Application. 2. Una directory WB-INF contenente: un file web.xml che descrive all'application server le servlet della web application una directory classes contenente tutte le classi delle nostre servlet e le loro helper classes (Proxy, Facade e quantaltro) esempio di un descrittore web.xml: <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd"> <web-app> <display-name>ccoon</display-name> <servlet> <param-value>/opt/programmi/jboss-3.0.0/server/default/template</paramvalue> <servlet-name>addccnservlet</servlet-name> <servlet-class>com.apat.ccoon.web.addccnservlet</servlet-class> <init-param> <param-name>template_path</param-name> </init-param> </servlet> 7
<servlet-mapping> <servlet-name>addccnservlet</servlet-name> <url-pattern>/addccnservlet</url-pattern> </servlet-mapping> </web-app> VI Applicazione di esempio La nostra applicazione di esempio che chiameremo tutorial avrà bisogno: di un database che chiameremo tutorial con almeno una tabella al suo interno di un application server J2EE (nell'esempio ci riferiremmo a jboss 3.0.x) di un DataSource connesso al database tutorial configurato sull'application server come detto in precedenza non ci occuperemmo di analizzare il codice del bean ma solo della parte della Web application. VI.1 Creazione del database e del datasource In questo paragrafo viene descritto come creare il database ed il datasource necessari a far funzionare l'esempio. Le istruzioni si riferiscono alla creazione del database su postgres 7.2 ed alla creazione del datasource su jboss 3.0.4. a Creazione del database Il database dell'applicazione di esempio si chiama ccoondb e contiene la tabella ccn. TABELLA CCN Nome del campo Tipo Descrizione id serial Chiave primaria dell centro di controllo Nome Varchar(24) Nome del centro di controllo Localita Varchar(24) Località in cui è situato il centro di controllo Rete Varchar(24) Nome della rete di appartenenza created timestamp Timestamp di quando è stato creato il record sul db last_update timestamp Timestamp di quando è il ccn si è collegato per aggiornare i dati latitudine Float8 longitudine 8
TABELLA CCN longitudine float8 latitudine Qui di seguito sono riportati i passi necessari alla creazione del database, viene assunto che postgres sia inizializzato e che il demone sia avviato. Dalla shell come utente postgres eseguire i comando: createdb ccoondb createlang plpgsql ccoondb psql ccoondb in questo modo si è creato il database ccoondb e si è entrati nel database ccoon conclient sql di postgres. A questo punto bisogna creare l'utente ccoon_admin con password puzzola per accedere al db con il seguente comando. create user ccoon_admin with password 'puzzola' createuser; \q uscire dalla shell dell'utente postgres l'utente cosi creato è l'owner del database ccoon e ha su di esso il massimo delle autorizzazioni. Si può scegliere di utilizzare per la connessione un utente avente solo i diritti necessari al funzionamento dell'applicazione ma questo va oltre lo scopo di questo documento. Bisogna quindi eseguire gli script sql per creare il data model e le stored procedure per fare ciò con la propria utenza. Digitare i seguenti comandi: psql ccoondb -U ccoon_admin \i [path di dove si estratta l'applicazione di esempio]/sql/cretedb.sql \i [path di dove si estratta l'applicazione di esempio]/sql/cretefunc.sql \q b Creazione del datasource Copiare i driver jdbc di postgres, pgjdbc2.jar nella directory: [path dell'installazione di jboss]/server/default/lib Copiare il file: [path di dove si estratta l'applicazione di esempio]/ccoon-pg-service.xml nella directory: [path dell'installazione di jboss]/server/default/deploy c Creazione della directory comune dei template Poiché le Velocity Servlet lavorano con un Singleton il path di dove sono messi i template di tutte le applicazioni deve essere comune. Creiamo quindi una directory per i template: 9
mkdir [path dell'installazione di jboss]/server/default/template Per comunicare alla servlet addccnservlet quale è la directory comune dei template bisogna metterela nel file web.xml nel segente modo: <servlet> <servlet-name>addccnservlet</servlet-name> <servlet-class>com.apat.ccoon.web.addccnservlet</servlet-class> <init-param> <param-name>template_path</param-name> <param-value>{path dell'installazione di jboss]/server/default/template</param-value> </init-param> </servlet> Le righe evidenziate in rosso sono quelle che passano il parametro alla servlet. in questa directory creiamo una directory CCOON che contiene i template della nostra applicazione e quindi una direcory template. mkdir [path dell'installazione di jboss]/server/default/template/ccoon mkdir [path dell'installazione di jboss]/server/default/template/ccoon/template Copiamo quindi in questa directory i template dell'applicazione. VI.2 Struttura dei package della applicazione Le servlet saranno nel package com.apat.ccon.web, le classi di utilità nel package com.apat.ccon.common, le classi dell'ejb nel package com.apat.ccon.ejb. Nei Prossimi paragrafi analizzeremmo i class diagram dell'applicazione realizzati con lo standard UML. Tali diagrammi servono a indicare come sono legate le classi e le interfaccie tra loro (legami di estenzione e di uso tra le classi) e i metodi che esse espongono. a Class Diagram dell'ejb Il Class Diagram di figura che rappresenta la struttura degli ejb dell'applicazione vi sono due classi: 1. CCOONSLEJB è un SessionBean e quindi vi saranno anche la Remote Interface e la Home Interface. La Remote Interface CCOONSL espone i metodi addccn, searchccn e deleteccn. La Home Interface espone il metodo ejbcreate. La classe CCOONSLEJB ha una un oggetto di tipo CCOONDAO. 2. CCOONDAO è una classe che si occupa di gestire l'accesso al database (da cui il nome DAO Database Access Object) ed espone i metodi addccn per aggiungere un Centro di Controllo Nazionale, searchccn per cercare un Centro di Controllo Nazionale, deletecnn per cancellare un Centro di Controllo Nazionale. 10
b Class Diagram della web application Figura 1 Class Diagram dell'ejb In Figura che rappresenta il Class Diagram della Web Application sono presenti quattro classi: CCOONServlet è una classe che implementa i metodi di utilità comuni a tutte le servlet. Nelnostro caso implementa per tutte le servlet i metodi init, loadconfiguration e handleapplicationexception che gestisce glie errori applicativi. AddCCNServlet: la classe estende la classe CCOONServlet da cui eredita tutti i metodi e nel metodo handlerequest gestisce la richiesta effettuata dal client. CCOONFacade: la classe si occupa di creare un ogetto CCOONProxy statico (questo è fatto per ottimizzare le prestazioni dell'applicativo) e ne chiama i metodi. CCOONProxy. La classe si occupa di interfacciarsi con l'ejb e di chiamare il metodo richiesto dal client. il metodo getccoonsl si occupa di creare la connessione con il bean, quindi fa il lookup dell'ejb, prende la Home Interface crea il Bean e fa il lookup della remote interface. 11
Figura 2 Class Diagram Della Web Application c Class Diagram delle classi di utilità comuni Figura 3 Class Diagram Delle Classi Di Utilità Comuni VI.3 Creazione della della funzionalità di aggiunta di un CCN Vediamo adesso come creare la funzionalità di aggiunta di un CCN. Tale funzionalità deve inserire un nuovo CCN (Centro di Controllo), i dati che identificano il CCN sono: id: identificativo univoco del CCN sul db e non è assegnato dall'utente name: il nome del CCN rete: rete a cui il CCN appartiene 12
località: località dove è situato il CCN latitudine: latitudine del CCN longitudine: longitudine del CCN Se l'inserimento è andato a buon fine la funzionalità dovrà visualizzare i dati immessi e l'id del CCN inserito, se si è verificato un errore dovrà ritornare un messaggio di errore all'utente. Per realizzare tale funzionalità bisogna creare: La pagina html per l'inserimento dei dati. La servlet: addccnservlet Il template per la visualizzazione dei dati inseriti. Aggiungere la servlet nel file web.xml che descrive la web application. a Creazione della pagina html per l'inserimento dei dati. Per passare i dati ad un server bisogna creare una pagina html con all'interno un oggetto form che contenga i campi da inviare alla servlet. Qui di seguito riportiamo il codice della pagina commentato contenuto nel file dell'applicazione di esempio /build/web/html/ccn_from.html. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> <html> <head> <title>ccnform</title> </head> <body> <!-- commento: tag di apertura di una form che all pressione del bottone submit manda i campi definiti al suo interno alla servlet /CCOON/AddCCNServlet --> <form action="/ccoon/addccnservlet" method="post"> <table width=300 cellspacing=2 border=0 cellpadding=2> <th colspan=2 bgcolor="lightgray"><font color="#c50000">form di inserimento dati di un CCN</font></th> <tr align="left " valign="center"> <td align="left">nome ccn</td> <!-- commento: campo name da passare alla sevlet --> <td align="left"><input type="text" name="name" size=24 maxlength=24></td> <tr align="left " valign="center"> <td align="left">località ccn</td> <!-- commento: campo località da passare alla sevlet --> <td align="left"><input type="text" name="localita" size=24 maxlength=24></td> 13
<tr align="center " valign="center"> <td align="left">rete ccn</td> <!-- commento: campo rete da passare alla sevlet --> <td align="left"><input type="text" name="rete" size=24 maxlength=24></td> <tr align="left" valign="center"> <td align="left">latitudine ccn</td> <!-- commento: campo latitudine da passare alla sevlet --> <td align="left"><input type="text" name="latitudine" size=24 maxlength=24></td> <tr align="left " valign="center"> <td align="left">longitudine ccn</td> <!-- commento: campo longitudine da passare alla sevlet --> <td align="left"><input type="text" name="longitudine" size=24 maxlength=24></td> <tr align="left " valign="center"> <td align="left"> </td> <!-- commento: bottone di tipo submit che invia i campi alla sevlet --> <td align="left"><input type="submit" name="submit" value="invia"></td> </table> </form> </body> </html> b Creazione del template di visualizzazione dei campi immessi A questo punto bisognerà creare un template per la visualizzazione dei dati immessi nel database. Un template per velocity permette di utilizzare i valori passati da una velocity servlet. Noi passeremmo un oggetto di tipo CCNVO che contiene i dati del CCN appena inserito sul db, e chiameremmo i metodi che restituiscono i dati contenuti nel CCN (metodi che iniziano con get). L'oggetto lo passeremmo con il nome ccnvo. Qui di seguito è riportato il codice del template contenuto nel file dell'applicazione di esempio build/template/manage_ccn.vm <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> <html> <head> <title>manage CCN</title> </head> <body> 14
<table width=300> <!-- commento: qui di sotto diciamo di inserire il valore ritornato dal metodo getname() dell'ogetto ccnvo --> <th colspan=2 bgcolor="lightgray"><font color="#c50000">dati del Centro di controllo $ccnvo.getname()</font></th> <tr align="center " valign="center"> <td width="90%"> <table> <tr> <td>id</td> <!-- commento: qui di sotto diciamo di inserire il valore ritornato dal metodo getid() dell'ogetto ccnvo --> <td>$ccnvo.getid()</td> <tr> <td>località</td> <!-- commento: qui di sotto diciamo di inserire il valore ritornato dal metodo getlocalità() dell'ogetto ccnvo --> <td>$ccnvo.getlocalita()</td> <tr> <td>rete</td> <!-- commento: qui di sotto diciamo di inserire il valore ritornato dal metodo getrete() dell'ogetto ccnvo --> <td>$ccnvo.getrete()</td> <tr> <td>longitudine</td> <!-- commento: qui di sotto diciamo di inserire il valore ritornato dal metodo getlongitudine() dell'ogetto ccnvo --> <td>$ccnvo.getlongitudine()</td> <tr> <td>latitudine</td> <!-- commento: qui di sotto diciamo di inserire il valore ritornato dal metodo getlatitudine () dell'ogetto ccnvo --> <td>$ccnvo.getlatitudine()</td> </table> </td> <td bgcolor="lightgray"> <table bgcolor="lightgray"> <tr> <td><input type="submit" disabled name="invia" value="edit" ></td> 15
<tr> size=10></td> <tr> <td><input type="submit" disabled name="invia" value="delete" <td><input type="submit" disabled name="invia" value="manage SM" size=10></td> </table> </td> </table> </body> </html> c Creazione della servlet AddCCNServlet Quando il bottone submit verra premuto dall'utente verra invocato il metodo handlerequest della servlet AddCCNServlet. La servlet dovrà estendere la classe CCOONServlet per ereditarne le funzionalità. La servlet dovrà prendere i campi inviati dall'utente, i parametri sono contenuti nell'oggetto request di tipo HttpServletRequest che viene passato come parametro al metodo handlerequest della servlet invocando su di esso il metodo getparameter(nomeparametro) il metodo getparameter ritornerà una stringa (più precisamente un oggetto di tipo String) contenente il valore del parametro se il parametro esiste, null se il parametro non esiste. Nel nostro caso ad esempio per prendere il parametro name userememmo l'istruzione request.getparameter( name ). Dovremmo quindi creare un oggetto di tipo CCNVO necessario come input al metodo addccn(ccnvo ccnvo) del CCOONFacade e valorizzarne i campi. Il CCNVO si occupa di controllare che il formato dei dati inseriti sia corretto. Una volta valorizzato il ccnvo si chiamerà il metodo addccn della classe CCOONFacade con a parametro il l'ogetto CCNVO da noi valorizzato. Tale metodo deve stare dentro un blocco try-catch perché lancia delle eccezioni. Nei blocchi catch vengono gestite le eccezioni e viene chiamato il metodo handleapplication exception ereditato dalla classe CCOONServlet, per la visualizzazione dell'errore all'utente. Qui di seguito riportiamo il codice commentato della servlet dell'applicazione di esempio contenuta nel file: com/apat/ccoon/web/addccnservlet. /* * APAT */ package com.apat.ccoon.web; 16
import javax.servlet.http.*; import javax.servlet.*; import java.util.*; import java.io.*; import com.apat.ccoon.common.*; // Import necessari ad utilizzare il parser velocity e la classe velocity servlet import org.apache.velocity.servlet.velocityservlet; import org.apache.velocity.context.context; import org.apache.velocity.template; import org.apache.velocity.app.velocity; import org.apache.velocity.exception.resourcenotfoundexception; import org.apache.velocity.exception.parseerrorexception; import org.apache.velocity.velocitycontext; /** * Description of the Class: La servlet estende la CCOONServlet e ne eredita * tutti i metodi. deve fare l'override del metodo in cui gestisce la richiesta * fatta dall'utente * * @author Paolo Picella * @created 8 dicembre 2002 * @Log $Log */ public class AddCCNServlet extends CCOONServlet { /** * Description of the Method: metodo che gestisce le richieste POST e GET * effettuate dall'utente * * @param request Vedi documentazione java * @param response Vedi documentazione java * @param ctxv Velocity Context * @return Template contenente il risultato dell'operazione eseguita */ public Template handlerequest(httpservletrequest request, HttpServletResponse response, Context ctxv) { // Creo un CCNVO vuoto in cui inserisco i parametri CCNVO ccnvo = new CCNVO(); // definisco il template con cui visualizzare i parametri 17
String templatename = "CCOON/template/manage_ccn.vm"; // inizializzo il messaggio di stato String message = "Successo"; // inizializzo il Velocity template Template outty = null; try { } // inserisco i parametri nel VO ccnvo.setname(request.getparameter("name")); ccnvo.setlocalita(request.getparameter("localita")); ccnvo.setrete(request.getparameter("rete")); ccnvo.setlongitudine(request.getparameter("longitudine")); ccnvo.setlatitudine(request.getparameter("latitudine")); // chiamo il metodo sul facade che mi inserisce i dati nel DB ccnvo = CCOONFacade.addCCN(ccnVO); // inserisco gli oggetti nel contesto Velocity ctxv.put("ccnvo", ccnvo); // Elaboro il template outty = gettemplate(templatename); // Gestisco le eccezioni applicative catch (CCOONException ccoone) { } outty = handleapplicationexception(ctxv, ccoone); System.out.println(message); // Gestisco le eccezioni generate nel parsing del template catch (ParseErrorException pee) { CCOONException ccoone = new CCOONException(CCOONConst.E_TEMPL, CCOONConst.ES_TEMPL + pee); } outty = handleapplicationexception(ctxv, ccoone); System.out.println(CCOONConst.ES_TEMPL + pee); // Gestisco le eccezioni generate caricamento del template catch (ResourceNotFoundException rnfe) { CCOONException ccoone = new CCOONException(CCOONConst.E_TEMPL, CCOONConst.ES_TEMPL + rnfe); } outty = handleapplicationexception(ctxv, ccoone); System.out.println("AddCCNServlet : template not found " + rnfe); //gestisco tutti gli altri tipi di eccezione catch (Exception e) { } System.out.println("Error " + e); // ritorno il template 18
} } return outty; d Inserimento della servlet nel file di configurazione Per inserire la servlet bisogna editare il file di configurazione build/web/web-inf/web.xml. In tale file bisogna inserire le linee di codice XML evidenziate in giallo nel listato qui di seguito riportato: <?xml version="1.0"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd"> <web-app> <display-name>ccoon</display-name> <servlet> <servlet-name>addccnservlet</servlet-name> <servlet-class>com.apat.ccoon.web.addccnservlet</servlet-class> <init-param> <param-name>template_path</param-name> <param-value>[path all'installazione di jboss]/server/default/template</param-value> </init-param> </servlet> <servlet> <servlet-name>searchccnservlet</servlet-name> <servlet-class>com.apat.ccoon.web.searchccnservlet</servlet-class> <init-param> <param-name>template_path</param-name> <param-value>[path all'installazione di jboss]/server/default/template</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>addccnservlet</servlet-name> <url-pattern>/addccnservlet</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>searchccnservlet</servlet-name> <url-pattern>/searchccnservlet</url-pattern> </servlet-mapping> </web-app> Nel tag servlet si definisce il nome che identifica la servlet, la classe che contiene il codice della servlet,i parametri da passare alla servlet. Come si può vedere noi passiamo un parametro template_path che contiene il path di dove sono installati i template. Nel tag <servlet-mapping> diamo l'uri della servlet. 19
VII Procedure di build, deploy ed installazione dell'applicazione di esempio. Le procedure di compilazione e di build sono state create con ant per eseguirle è necessario quindi scaricare ant dal sito http://ant.apache.org/. Per compilare l'applicazione bisogna eseguire dalla directory Tutorila-EJB il comando: ant compilaweb Per creare il file ear che contiene l'applicazione bisogna eseguire dalla directory Tutorila-EJB il comando: ant deploy per installare l'applicazione bisogna copiare il file ccoon.ear nella direcotry: [path di dove è installato Jboss]/server/default/deploy. VIII Riferimenti Jakarta Velocity - http://jakarta.apache.org/velocity/user-guide.html Java Servlet - http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/servlets.html ant http://ant.apache.org/ Sun Java2EE Tutorial http://java.sun.com/j2ee/tutorial/1_3-fcs/index.html Sun Java2SE Tutorial http://java.sun.com/docs/books/tutorial/index.html Editor Java Free http://www.jedit.org/ Thinking in Java 2 nd edition http://www.planetpdf.com/codecuts/pdfs/eckel/tij2.zip Jboss Java2EE Application Server http://www.jboss.org/ 20