Progetto Jug4Tenda. WORK IN PROGRESS di Andrea Del Bene

Transcript

1 Indice generale Progetto Jug4Tenda WORK IN PROGRESS di Andrea Del Bene Progetto Jug4Tenda...1 Nota...2 1Configurazione ambiente di lavoro ed esecuzione del progetto Requisiti software Installazione Java JDK Installazione MySql Installazione di Eclipse e Tomcat Test e configurazione dell'installazione MySql Scaricare con Eclipse il sorgente dal repository CVS del progetto Struttura delle cartelle Costruzione del database Il file dbparamters.properties Configurazione Tomcat in eclipse Il processo di sviluppo Prima fase: i meeting Seconda fase: tracciatura dei requisiti Terza fase: sviluppo Quarta fase: commit delle modifiche Quinta fase: branching del sorgente Manutenzione: correzione bug sulla versione in produzione Diagramma di attività delle fasi descritte Mappa delle tecnologie usate Architettura e codice ATTENZIONE!! Nota Il file web.xml Spring MVC Codice di ospitecontroller...25 Andrea Del Bene Progetto Jug4Tenda 1 / 26

2 Nota Come modello per questo documento è stato preso il template dei documenti Write di OpenOffice disponibile sul sito dello JUG Sardegna. Si ringrazia il JUG Sardegna per la cortese collaborazione. Il documento è in costante aggiornamento e il paragrafo 3 Architettura e codice è ancora incompleto. Se ci sono domande/dubbi urgenti sul codice sorgente o sull'architettura si possono porre le proprie domande sul forum del progetto (previa iscrizione) o mandando una mail alla mailing list di sviluppo jug4tendadev@googlegroups.com o ancora più comodamente ad andrea.on.web@libero.it. L'autore di questa guida (Andrea Del Bene) è presente anche su Facebook per coloro che vogliano interagire usando questo network. Andrea Del Bene Progetto Jug4Tenda 2 / 26

3 1 Configurazione ambiente di lavoro ed esecuzione del progetto. 1.1 Requisiti software Per iniziare a lavorare sul progetto Jug4Tenda occorre procurarsi i seguenti programmi: 1. Java JDK (versione 5.0 o superiore) 2. MySql (versione 5.0 o superiore) 3. Tomcat ( versione 5 o superiore) 4. Eclipse (versione 3.3 o superire) Installazione Java JDK Sotto ambiente Windows Java è disponibile come installatore eseguibile all'indirizzo Sotto ambiente Linux può essere installato l'openjdk se disponibile nei repository ufficiali delle varie distribuzioni. Di seguito riportiamo le istruzioni per installare il JDK scaricato all'indirizzo sopra indicato per Windows su un sistema Linux Debian. Le istruzioni sono riprese dal sito dello Jug Sardegna Alla pagina del download si sceglie la distribuzioni a seconda del proprio hardware e del proprio sistema operativo. Nel nostro esempio useremo il file jdk-6u11-linux-i586.bin. Scaricato il file spostiamolo nella cartella di installazione, ad esempio /usr/local, usando il comando: sudo mv jdk-6u11-linux-i586.bin /usr/local Ora ci spostiamo nella cartella di installazione e lanciamo l'installatore dopo aver reso il file eseguibile: cd /usr/local chmod +x jdk-6u11-linux-i586.bin sudo sh jdk-6u11-linux-i586.bin L'installatore ci chiederà di accettare la licenza. Terminata l'installazione si può cancellare l file jdk-6u11-linux-i586.bin. L'installazione è completa ma occorre indicare al sistema che la distribuzione java da usare è quella appena installata. Il comando seguente serve proprio ad avvisare Linux che c'è una nuova distribuzione Java nel sistema: sudo update-alternatives --install /usr/bin/java java /usr/local/jdk1.6.0_11/bin/java 300 La sottocartella jdk1.6.0_11 è volutamente evidenziata perchè è stata creata dall'installatore e riporta la versione correntemente installata. Per concludere dobbiamo impostare il nuovo jdk come implementazione di default: sudo update-alternatives --config java Questo comando mostrerà tutte le installazioni di Java presenti nel sistema numerandole. Possiamo ora specificare il numero corrispondente al JDK appena installato per renderlo l'implementazione Java di deffault. Andrea Del Bene Progetto Jug4Tenda 3 / 26

4 1.1.2 Installazione MySql Sotto ambiente Windows MySql è disponibile come installatore eseguibile all'indirizzo In ambiente Linux è possibile affidarsi al proprio gestore di pacchetti/programmi che si occupa in automatico di cercare MySql, scaricarlo, installarlo e configurarlo. Illustrazione 1: Gestione applicazioni sotto Xubuntu NOTA: si consiglia anche l'installazione del MySql Administrator per agevolare la gestione del database e le operazioni di routine Installazione di Eclipse e Tomcat Per seguire le istruzioni di questo manuale è sufficiente scaricare i due programmi sotto forma di archivio zip o tar e decomprimerli in una cartella nel nostro sistema. Tomcat si può trovare sul sito ufficiale ed anche Eclipse dispone di un sito da cui scaricare l'ultima versione: NOTA: benchè non occorrano particolari distribuzioni di Eclipse o plugin per lavorare con il progetto Jug4Tenda, sono richiesti i tool di sviluppo lato server per lanciare Tomcat da Eclipse. Tali strumenti sono solitamente inclusi nelle distribuzioni di Eclipse per lo sviluppo enterprise (JEE). Nel paragrafo XX vengono anche elencati degli strumenti consigliati per lavorare con il codice del progetto in maniera ottimale. 1.2 Test e configurazione dell'installazione MySql Ora dobbiamo assicurarci di conoscere i parametri fondamentali per connetterci a MySql. Per fare ciò useremo l'utility MySql Administrator. I parametri fondamentali sono l'host su cui è stato installato MySql (può essere il nostro sistema locale localhost), la porta su cui è stato installato (di default la 3306) ed infine il profile utente (username e password) di MySql con cui vogliamo lavorare. Sul nostro sistema di sviluppo può essere comodo lavorare con l'username root per Andrea Del Bene Progetto Jug4Tenda 4 / 26

5 avere pieni diritti d'uso su MySql. La password di default dell'utente root è vuota. Se abbiamo fatto un'installazione locale senza specificare una password per l'utente root dovremmo avere una schermata simile all'avvio di MySql Administrator. I parametri di connessione a MySql ci torneranno utili in seguito nel paragrafo 1.6 quando dovremo impostare il file con i parametri di connessione a MySql. 1.3 Scaricare con Eclipse il sorgente dal repository CVS del progetto Eclipse è l'ide usato per il progetto Jug4Tenda ed offre ampio supporto per lavorare su un repository CVS. Per avviare Eclipse è sufficiente andare nella cartella in cui si decompresso l'arcivio della distribuzione scaricata. Qui si troverà il file eseguibile da lanciare per avviare l'ide (un file eclipse.exe se siamo sotto Windows eclipse.sh se siamo sotto Linux). Al primo avvio Eclipse richiederà la cartella da usare come continetore dei progetti su cui lavoreremo (workspace di Eclipse). Di default viene proposta una cartella workspace posizionata nella cartella utente (es: / home/andrea/workspace sotto Linux o C:\Documents and Settings\andrea\workspace) NOTA: per seguire le istruzioni di questa guida non è richiesta la conoscenza sul funzionamento di CVS o di un altro sistema per il controllore di versione. Tuttavia avere una minima conoscenza di questa tipologia di software rende più facile la comprensione del testo. Un ottimo tutorial (in lingua inglese) introduttivo sull'argomento lo si può tovare al seguente indirizzo. Il progetto ha il suo reporitory ufficiale esplorabile tramite browser al seguente indirizzo. Per scaricare il sorgente con Eclipse è sufficiente seguire le seguenti istruzioni e non è necessaria nessuna conoscenza relativa all'ide. Per connettersi al repository si clicchi sulla voce di menù File Import, si scelga Project from CVS e si proceda con 'Next' Andrea Del Bene Progetto Jug4Tenda 5 / 26

6 Per connettersi al repository occorre fornire alla prima connessione I parametri per identificare il repository ed autenticarsi. Nel wizard si sceglie quindi Create a new repository location. I dati necessari per creare un account generico sono i seguenti: Host: cvs.dev.java.net Repository path: /cvs Username: guest Password non necessaria Connection type:pserver Andrea Del Bene Progetto Jug4Tenda 6 / 26

7 Ora cliccando su 'Next' dovremmo riuscire ad autenticarci con il repository. Nella schermata successiva ci viene chiesto quale modulo (ossia quale cartella) si desidera scaricare. E' sufficiente scrivere'jugancona/jug4tenda' e premere 'Next'. Andrea Del Bene Progetto Jug4Tenda 7 / 26

8 In alternativa oltre a scrivere direttamente la sottocartella voluta si possono esplorare tutte le cartelle e sottocartelle del repository selezionando 'Use an existing module'. Ora non rimane che selezionare la cartella del nostro 'workspace' dove verrà scaricato il sorgente: Premendo 'Finish' inizierà il download del progetto che verrà aperto in automatico da Eclipse al termine del trasferimento dati. 1.4 Struttura delle cartelle La struttura attuale delle cartelle del progetto è la seguente: Di seguito riportiamo una breve descrizione delle cartelle del progetto: doc: contiene la documentazione del progetto ossia le pagine html JavaDoc e un documento di reference scritto con OpenOffice Writer lib: contiene i jar delle librerie usate dall'applicazione (Hybernate, Spring, Jakarta Common, ecc...). model: in questa cartelle ho inserito il modello delle classi in argo per averlo sempre disponibile assieme al progetto (è visibile tramite l'apposito plugin). Il file comunque io non l'ho modificato e se si volessero far modifiche considero valido quello disponibile nella sezione download del sito e non questo sul cvs. src: è la cartella più interessante :-) ossia quella dei sorgenti. Le sue sottocartelle hibernateconfigfiles e springconfigfiles contengono i file xml di configurazione dei Andrea Del Bene Progetto Jug4Tenda 8 / 26

9 rispettivi framework. Come ho detto vengono copiate in automatico nella cartella bin ad ogni modifica che viene fatta ai file xml. setup: contiene gli script sql per creare il database di lavoro del progetto. webapp: in questa cartella ci sono i binari (bytecode) del progetto e tutti i file di supporto per la parte web del progetto (immagini, pagine jsp/html, css, direcory WEB-INF, ecc...) 1.5 Costruzione del database Nel pragrafo 1.2 ci siamo connessi a MySql per verificare che non ci fossero problemi e per conoscere i parametri richisti per connettersi. Adesso utilizziamo nuovamente MySql Administrator per ricostruire il database di lavoro di Jug4Tenda Illustrazione 1: schermata iniziale di MySql Administrator Per ripristinare il database di lavoro occorre usare la funzione Restore Backup dal menù di sinistra. In questa funzione occorre specificare la cartella setup del progetto che contiene gli script sql per ricostruire le tabelle e le viste del progetto. A questo scopo si usa il pulsante Change path... in basso a sinistra. Andrea Del Bene Progetto Jug4Tenda 9 / 26

10 Illustration 2: Configurazione per il ripristino dei backup Il file principale da lanciare è db_setup.sql, seguito da functionandsp.sql. Per lanciarli è sufficiente selezionarli e cliccare su Reerestore Backup. Selezionando i file viene chiesto il charset da usare per leggerli.si può scegliere per entrambi il set latin1. Alla fine avremo un database nominato jug4tenda pronto per essere usato. 1.6 Il file dbparamters.properties Ora dobbiamo preoccuparci di far conoscere al progetto questi dati in modo che si possa collegare al database di lavoro senza problemi. Il problema con cui ci si deve subito confrontare è che inserire queste informazioni (db url, username e password) nel repository o peggio ancora nel codice darebbe luogo ad una situazione molto scomoda in cui ogni volta che "salviamo" il progetto sul repository (comando Commit...) andiamo anche a salvare le informazioni relative alla nostra installazione di MySql. Chi dopo di noi andrà a prendere il progetto si ritroverà quindi le nostre informaioni di login al database e dovrà modificarle. Quando poi salverà le sue modifiche al sorgente si ripeterà, per un altro di noi, il circolo diabolico che ho descritto adesso...penso di aver reso l'idea :-)! Nel progetto ho quindi centrlizzato le informazioni di login in un file dbparamters.properties (sotto src/springconfigfiles) che viene letto quando bisogna connettersi al database. In seguito...ho rimosso queso file dal repository! In questo modo ovviamnte quando si importa il progetto dal CVS il file dbparamters.properties non viene scaricato, però potete scaricare la copia che ho rimosso dal CVS con pochi click sul navigator di Eclipse. Portandosi sulla cartella src/springconfigfiles si prema il tasto destro, si selezioni il menù Team e si lanci Restore from Repository Andrea Del Bene Progetto Jug4Tenda 10 / 26

11 Nella finestra che appare si scelga il file dbparamters.properties e l'ultima revisione disponibile come mostrato in figura: Cliccando Finish si ritriva il file nel proprio progetto, ovviamente alla posizione src/springconfigfiles e non sarà controllato dal CVS. In questo modo ognuno di noi dovrà modificare il file dbparamters.properties solo una volta e non lo condividerà con nessuno. Inoltre abbiamo evitato di inserire dei parametri testuali dentro il codice centralizzandole in un file di testo. Ora la nostra applicazione, sia che facciamo test sia quando la metteremo in produzione userà questo file per connettersi a MySql. Andrea Del Bene Progetto Jug4Tenda 11 / 26

12 1.7 Configurazione Tomcat in eclipse Tramite Eclipse è possibile lanciare e fermare Tomcat in modo da far girare il progetto Jug4Tenda o una qualsiasi altra web application a cui si sta lavorando con Eclipse. Per configurare questa funzionalità per prima cosa dobbiamo aprire la vista Server di Eclipse. Possiamo attivare le viste usando la voce sotto Windows Show View Other... come mostrato in figura Illustrazione 3: Gestione delle viste disponibili Dalla finestra Show View scegliamo la vista servers, possiamo trovarla rapidamente usando il campo di ricerca. Illustrazione 4: vista servers Andrea Del Bene Progetto Jug4Tenda 12 / 26

13 Al primo utilizzo la vista servers ovviamente non mostrerà alcun elemento. Facendo click con il tasto destro e selezionando New...andiamo ad aggiungere la nostra instalalzione di Tomcat: Illustrazione 5: Creazione di un nuovo profilo server Il wizard di creazione di un nuovo profilo server ci chiede anzi tutto che tipo di profilo vogliamo creare (Tomcat 5.5 nel nostro caso) e successivamente tramite il pulsante Installed Runtime dobbiamo indicare la cartella in cui abbiamo estratto l'archivio di Tomcat precedentemente scaricato: Illustrazione 6: Scelta del tipo server da creare Andrea Del Bene Progetto Jug4Tenda 13 / 26

14 Illustrazione 7: Il wizar richiede la cartella di installazione di Tomcat Ora nella nostra vista servers vediamo la configurazione appena creata: Illustrazione 8: Il nostro Tomcat è pronto per partire! Prima di poter lanciare finalmente Tomcat dobbiamo indicargli dov'è il nostro progetto Jug4Tenda in modo che possa attivarlo in fase di avvio. Procediamo facendo doppio click sulla configurazione appena creata. Si aprirà una finestra con due schede, Overview e Modules. Portiamoci su Modules come mostrato in figura: Andrea Del Bene Progetto Jug4Tenda 14 / 26

15 Illustrazione 9: I moduli di Tomcat A questo punto non c'è molta scelta :-), dobbiamo cliccare su Add External Web Module per aggiungere il progetto Jug4tenda tra le applicazioni disponibili: Illustrazione 10: Aggiunta di un modulo web Per aggiungere un modulo web dobbiamo indicare nella prima casella la cartella del progetto webapp. Ad esempio sotto Linux posta la cartella del nostro workspace /home/andrea/workspace e posta la cartella del progetto Jug4tenda, la cartella da specificare sarà: /home/andrea/workspace/jug4tenda/webapp Sotto Windows: C:\Documents and Settings\andrea\workspace\Jug4Tenda\webapp Infine il parametro Path è l'url relativo che dobbiamo scrivere per accedere al mosulo del progetto Jug4tenda. Quando Tomcat sarà attivo vi si potrà accedere in locale tramite l'url Per accedere al nostro modulo dovremmo concatenare quanto scriveremo come parametro Path. Se mettiamo Jug4Tenda accederemo al modulo all'indirizzo Andrea Del Bene Progetto Jug4Tenda 15 / 26

16 ATTENZIONE: l'url è case sensitive, Jug4Tenda è diverso da jug4tenda!!!) Per ora trascuriamo l'opzione di Auto Reloading utile in fase di sviluppo, anche se affetta da un bug di memory overflow, almeno sino ad Eclipse 3.3 Il risultato finale dei nostri sforzi dovrebbe assomigliare a quanto segue: Illustrazione 11: Tutto per la prima esecuzione! Andrea Del Bene Progetto Jug4Tenda 16 / 26

17 2 Il processo di sviluppo Di seguito vengono elencati le fasi che compongono il ciclo di sviluppo del progetto. L'idea è quella di formalizzare il cammino che gli sviluppatori seguono per ricevere nuove richieste di implementazioni, per realizzarle e per pubblicarle (e condividerle). L'ultima fase riguarda la manutenzione della versione del progetto rilasciata e in produzione. Viene anche descritto come interaggiscono gli sviluppatori con il loro committente (casa di accoglienza Tenda di Abramo) 2.1 Prima fase: i meeting Il processo di sviluppo parte da incontri tra sviluppatori e rappresentanti della casa di accoglienza. Durante questi eventi si produce una prima bozza del documento dei requisiti che viene esaminato dagli sviluppatori e integrato dai committenti in maniera iterativa fino ad ottenere delle specifiche chiare e condivise tre sviluppatori e rappresentanti della tenda. Le specifiche possono riguardare nuove implementazioni, migliorie di funzionalità già presenti o bug fix. Esistono figure intermedie con competenze tecniche e che operano come volontari all'interno della tenda che agevolano il dialogo tra il gruppo tecnico e i responsabili della tenda. Oltre al documento dei requisiti spesso vengono prodotti anche documenti tecnici come diagrammi delle classi UML relativi alle classi di dominio: 2.2 Seconda fase: tracciatura dei requisiti Tramite mailing list del progetto (creata su Google) viene prodotto e distribuito una sorta di resoconto del meeting, comprese le specifiche elaborate. Le specifiche del meeting vengono anche inserite in un issue tracker presente sul sito del progetto (sito della Sun dev.java) per tenere traccia del loro avanzamento e per poterle assegnare ai singoli sviluppatori. Gli avanzamenti nello sviluppo dei singoli issue vengono notificati in automatico all'intero gruppo di sviluppo tramite mailing list. 2.3 Terza fase: sviluppo. Lo sviluppo si avvale di un repository cvs (upgradabile a Subversion) tramite il quale vengono condivisi i vari artefatti prodotti dagli sviluppatori (file java, pagine jsp, file sql, ecc...). Il sistema cvs si occupa del versioning dei vari file e gestisce le eventuali situazioni di conflitto tra file modificati contemporaneamente da più sviluppatori. Come vedremo il repository cvs viene usato nella fase finale di rilascio anche per produrre branch delle versioni messe in produzione presso la tenda. Gli sviluppatori sono tenuti ad aggiornarsi regolarmente dal branch principale del repository in modo da lavorare sempre su una copia aggiornata del sorgente. Ciò consente di affrontare tempestivamente eventuali conflitti di risorse e per integrare il proprio codice con le ultime modifiche fatte dal resto del gruppo. Lo sviluppo vero e proprio ruota attorno alle classi di dominio che riflettono i diagrammi UML prodotti e che sono quindi i primi artefatti prodotti dallo sviluppatore. Le classi sono puri POJO (Plain Old Java Object) ossia semplici JavaBean che non implementano alcuna interfaccia aventi solo proprietà private e relativi getter e setter. Le fase successive dello sviluppo seguono un approccio bottom-up che ruota sempre attorno alle classi di dominio. Vengono sviluppati preposti alla gestione delle classi di dominio in accordo con i requisiti espressi nelle specifiche. In ordine di norma vengono sviluppati i seguenti artefatti: Andrea Del Bene Progetto Jug4Tenda 17 / 26

18 1) Interfacce DAO per la gestione delle classi di dominio, in particolare le interfacce specificano le classiche operazioni CRUD e operazioni speciali imposte dai requisiti. Di queste interfacce si realizzano implementazioni a seconda della tecnologia di persistenza scelta (JDBC, Hibernate, Top Link, ecc...). 2) Classi di coordinamento (controller) che fanno da tramite tra l'interfaccia web vera e propria e le implementazioni DAO usate dal progetto. 3) Pagine jsp che consentono all'utente di interagire con le entità di dominio in accordo con le specifiche. A questi strati implementativi possono ovviamente essere aggiunti altri strati intermedi, ad esempio uno strato di validazione dei dati inseriti dall'utente. La cosa fondamentale da rispettare è che nessuno strato dipenda (ossia abbia visibilità) da uno strato superiore, ossia più vicino alla GUI. Si deve evitate ciò per almeno due buoni motivi: Non creare delle dipendenze tra oggetti a forte astrazione (classi di dominio, DAO, ecc...) e oggetti legati ad una particolare tecnologia implementativa (Spring MVC, protocollo HTTP, JSP, ecc...) Non creare dipendenze circolari di alcun tipo, non solo a livello di codice Java ma anche a livello funzionale. Ad esempio gli strati di presentazione (JSP) o di controller dipendono dalle classi di dominio (strato più in basso). Se valesse anche il viceversa le modifiche fatte a livello di presentazione di rifletterebbero anche sulle classi di dominio! (cit. Jurgen Holler, 2007) Oltre alla realizzazione degli artefatti visti gli sviluppatori sono tenuti a scrivere test unitari (JUnit) che certifichino un comportamento logicamente corretto e che soddisfi i requisiti. 2.4 Quarta fase: commit delle modifiche Quando lo sviluppatore termina le sue implementazioni prima di caricare le modifiche sul repository occorre rilanciare tutti i test unitari realizzati nel progetto, al fine di identificare in maniera tempestiva problemi di integrazione del nuovo codice con le funzioni esistenti e per evitare bug di regressione. Passati tutti i test unitari può essere eseguito il commitment del codice realizzato. In generale vale la seguente regola: non si deve fare il commitment di codice non consistente, ossia codice che non supera tutti i test unitari. La suddetta regola serve per assicurare che ogni membro del team di sviluppo lavori su una copia del sorgente aggiornata senza test fallimentari. 2.5 Quinta fase: branching del sorgente Mano a mano che si realizzano implementazioni e le si caricano sul repository, con l'aiuto del personale della tenda si fanno i primi test su strada e si raccolgono le impressioni degli utenti e in Andrea Del Bene Progetto Jug4Tenda 18 / 26

19 caso si procede modificando il codice alla luce delle loro osservazioni. Quando si raggiunge un numero sufficiente di implementazioni realizzate e testate si decide di congelare il sorgente creando un branch che contiene tutti gli artefatti con i quali andremo a produrre la nuova versione del progetto da mettere in produzione. Una volta creato il branch per l'ultima versione da rilasciare i lavori di nuove implementazioni possono tranquillamente proseguire sul branch principale (chiamato HEAD). 2.6 Manutenzione: correzione bug sulla versione in produzione Nei casi in cui vengano segnalati dei bug sulla versione in produzione le operazioni di bug fix non vengono realizzate sul branch del sorgente principale HEAD bensì sul branch realizzato per fare il deployment della versione in produzione. In questo modo il bug fix viene risolto sulla versione in produzione e non si è costretti a fornire al committente una nuova versione presa dal branch HEAD con nuove funzionalità provvisorie e peggio ancora non ancora opportunamente testate. Il sistema cvs consente poi di fare un merge delle varie fix sul branch principale HEAD, in modo che la prossima release del programma non ripresenti nuovamente i bug segnalati in una versione precedente. 2.7 Diagramma di attività delle fasi descritte Andrea Del Bene Progetto Jug4Tenda 19 / 26

20 2.8 Mappa delle tecnologie usate Spring taglib DisplayTag lib Format taglib Web browser AOP DI Bean Lifecycle manager Classi Utility Spring MVC... Componenti Spring MVC custom DAO con servizi dichiarativi (transazione,ecc...) Hibernate integ. Compass integ. Data connection Spring framework Hibernate/JDBC driver Compass/Lucene Web container (Tomcat) Database MySql Andrea Del Bene Progetto Jug4Tenda 20 / 26

21 3 Architettura e codice 3.1 ATTENZIONE!! Nell'implementazione corrente viene fatto uso di un Handler Interceptor, non descritto in questa versione del documento di reference. Si provvederà quanto prima ad allinearlo con il sorgente. 3.2 Nota Il seguente documento intende dare le informazioni basilari per comprendere la configurazione della parte web del progetto Jug4Tenda. Come prerequisito si richiede una conoscenza minima di Spring e del funzionamento del suo container tramite file di configurazione xml. Per ovvi motivi di tempo e di spazio non saranno quindi trattati i concetti base di Spring e la sua integrazione con Hibernate. 3.3 Il file web.xml Come per ogni applicazione web Java il file web.xml (nella cartella WEB-INF) contiene tutte le informazioni che il web container (Tomcat nel nostro caso) andrà ad utilizzare per caricare e rendere operativa la nostra applicazione. Nel nostro caso la porzione più significativa del file è la seguente: servlet> <servlet-name>jug4tenda</servlet-name> <servlet-class> </servlet-class> <init-param> org.springframework.web.servlet.dispatcherservlet <param-name>contextconfiglocation</param-name> <param-value> classpath:springconfigfiles/jug4tendacontext.xml </servlet> </init-param> <servlet-mapping> </servlet-mapping> </param-value> <load-on-startup>1</load-on-startup> <servlet-name>jug4tenda</servlet-name> <url-pattern>*.html</url-pattern> <!-- The Usual Welcome File List --> <welcome-file-list> </welcome-file-list> <welcome-file>index.htm</welcome-file> Estratto del file web.xml Nel tag <servlet> specifichiamo il nome della nostra applicazione (Jug4Tenda) e, cosa più importante, la servlet che che viene lanciata e associata alla nostra applicazione al momento dell'avvio del web container. La servlet è del tipo org.springframework.web.servlet.dispatcherservlet. Facendo un salto più in basso troviamo il tag <servlet-mapping> dove indichiamo quali richieste, ossia quali URL verranno indirizzati alla nostra servlet Jug4Tenda: tutti gli URL terminanti con html verranno gestiti dalla servlet Jug4Tenda. Andrea Del Bene Progetto Jug4Tenda 21 / 26

22 NOTA: per evitare confusione è ben dire che un url terminante con html NON deve per forza riferirsi ad un corrispondente file html esistente. Può anche essere un URL di pura fantasia, la cosa importante è che se termina con html verrà girato alla nostra servlet. Il tag <init-param> che abbiamo volutamente ignorato contiene la posizione del file di configurazione di Spring che la nostra servlet si aspetta di caricare al suo avvio. Nel tag <welcome-file-list> indichiamo quale sarà la pagina html visualizzata come homepage del nostro progetto. Ora dopo aver analizzato concetti di configurazione abbastanza generico entreremo più nel dettaglio del funzionamento del framework Spring MVC. 3.4 Spring MVC Il ponte di ingresso della nostra applicazione con il mondo esterno è la servlet Dispatch Servlet che abbiamo visto configurata nel file web.xml. Tutte le request indirizzate alla nostra applicazione transitano per questa servlet che le reindirizza alle varie componenti della nostra web application. Vedremo ovviamente cosa sono queste componenti che gestiscono le request e vengono configurate nel file di contesto di Spring. E' il momento di mostrare il cammino classico di una request all'interno dell'architettura di un'applicazione Spring MVC. Di seguito si riporta un semplice diagramma a blocchi: Diagramma di Spring MVC Concetriamo la nostra attenzione sui blocchi azzurri che corrispondono ai passi 1,2,3,4. La request giunge dal nostro browser alla dispatch servlet (passo 1). In base all'url richiesto la servlet deve attivare una specifica parte di controllo (passo 2 e 3). Quest'ultime sono classi che implementano l'interfaccia Controller del framework e hanno il compito di processare le request http. Passiamo subito ad un esempio: Andrea Del Bene Progetto Jug4Tenda 22 / 26

23 1) Digito nel browser (Passo 1) Per quanto detto prima riguardo il file web.xml le richieste di pagine html sono gestite dalla Dispatch Servlet 2) Sappaiamo che la nostra applicazione Spring MVC all'avvio carica il file di contesto jug4tendacontext.xml. In esso sono specificate le regole di associazione URL --> Controller che deve seguire la Dispatch Servlet. Se analiziamo il file in questione troviamo le seguenti impostazioni di configurazione: <bean id="ospitecontroller" class="org.jugancona.jug4tenda.web.controllers.ospitecontroller">... <property name="methodnameresolver"> <ref bean="methodnameresolver"/> </property> </bean> <bean id="urlmapping" class="org.springframework.web.servlet.handler.simpleurlhandlermapping"> </bean> <property name="mappings"> <props> <prop key="/*ospite.html">ospitecontroller</prop> </props> </property> <bean id="methodnameresolver" class="org.springframework.web.servlet.mvc.multiaction.parametermethodnameresolver"> </bean> <property name="paramname"> </property> <value>param</value> Configurazione del controller ospitecontroller. Uno dei due bean configurati è di tipo handler mapping (Passo 2). Al suo interno nel tag <prop.../> viene dichiarato che tuti gli URL che terminano con Ospite.html verranno passati ad ospitecontroller. Il primo bean che troviamo è proprio ospitecontroller 3) Siamo ormai giunti al passo 3, la request è stata passata al controller ospitecontroller che si appresta a processarla. La classe controller oltre ad implementare l'interfaccia Controller di Spring MVC discende da una classe preconfezionata del framework, la MultiActionController. La sua particolarità risiede nel fatto che può richiamare diversi metodi per processare la request analizzando il contenuto dell'url. Nel file di contesto abbiamo dichiarato che il nostro controller referezia il bean methodnameresolver il quale a sua volta ha la proprietà paramname impostata come param. Tradotto in parole povere il controller analizza l'url alla ricerca di un parametro param e tenta di invocare il suo metodo che come nome ha il valore di param. Andrea Del Bene Progetto Jug4Tenda 23 / 26