Progetto Jug4Tenda

Transcript

Progetto Jug4Tenda

Java User Group Marche
http://www.jugancona.org – [email protected]
Progetto Jug4Tenda
WORK IN PROGRESS
di Andrea Del Bene
Indice generale
Progetto Jug4Tenda.......................................................................................................1
Nota.......................................................................................................................2
1Configurazione ambiente di lavoro ed esecuzione del progetto..............................3
1.1Requisiti software ............................................................................................3
1.1.1Installazione Java JDK................................................................................3
1.1.2Installazione MySql....................................................................................4
1.1.3Installazione di Eclipse e Tomcat..............................................................4
1.2Test e configurazione dell'installazione MySql.................................................4
1.3Scaricare con Eclipse il sorgente dal repository CVS del progetto..................5
1.4Struttura delle cartelle.....................................................................................8
1.5Costruzione del database..................................................................................9
1.6Il file dbParamters.properties.........................................................................10
1.7Configurazione Tomcat in eclipse...................................................................12
2Il processo di sviluppo...........................................................................................17
2.1Prima fase: i meeting......................................................................................17
2.2Seconda fase: tracciatura dei requisiti...........................................................17
2.3Terza fase: sviluppo........................................................................................17
2.4Quarta fase: commit delle modifiche..............................................................18
2.5Quinta fase: branching del sorgente...............................................................18
2.6Manutenzione: correzione bug sulla versione in produzione.........................19
2.7Diagramma di attività delle fasi descritte.......................................................19
2.8Mappa delle tecnologie usate.........................................................................20
3Architettura e codice ............................................................................................21
3.1ATTENZIONE!!...............................................................................................21
3.2Nota................................................................................................................21
3.3Il file web.xml.................................................................................................21
3.4Spring MVC....................................................................................................22
3.5Codice di ospiteController..............................................................................25
Andrea Del Bene – Progetto Jug4Tenda
1 / 26
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 [email protected] o ancora più comodamente ad
[email protected].
L'autore di questa guida (Andrea Del Bene) è presente anche su Facebook per coloro che
vogliano interagire usando questo network.
2 / 26
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.1.1
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
http://java.sun.com/javase/downloads/index.jsp. 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.
3 / 26
1.1.2
Installazione MySql
Sotto ambiente Windows MySql è disponibile come installatore eseguibile all'indirizzo
http://dev.mysql.com/downloads/. 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.
1.1.3
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 http://tomcat.apache.org ed anche Eclipse dispone di un sito da cui scaricare l'ultima
versione: http://www.eclipse.org/downloads/.
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
4 / 26
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'
5 / 26
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
6 / 26
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'.
7 / 26
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
8 / 26
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.
9 / 26
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”
10 / 26
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
src/springConfigFiles e non sarà controllato dal CVS.
progetto,
ovviamente
alla
posizione
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.
11 / 26
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
disponibili
3:
Gestione
delle
viste
Dalla finestra Show View scegliamo la vista servers, possiamo trovarla rapidamente usando il
campo di ricerca.
Illustrazione 4: vista servers
12 / 26
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
13 / 26
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:
14 / 26
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
http://localhost:8080. Per accedere al nostro modulo dovremmo concatenare quanto scriveremo
come parametro Path. Se mettiamo Jug4Tenda accederemo al modulo all'indirizzo
15 / 26
http://localhost:8080/Jug4Tenda.
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!
16 / 26
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:
17 / 26
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
18 / 26
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
19 / 26
2.8 Mappa delle tecnologie usate
Spring taglib DisplayTag lib Format taglib
AOP
DI
Web browser
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
Database
MySql
Web container (Tomcat)
20 / 26
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>
org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:springConfigFiles/jug4tendaContext.xml
</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Jug4Tenda</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>

<welcome-file-list>
<welcome-file>index.htm</welcome-file>
</welcome-file-list>
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.
21 / 26
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:
22 / 26
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">
<property name="mappings">
<props>
<prop key="/*Ospite.html">ospiteController</prop>
</props>
</property>
</bean>
<bean id="methodNameResolver"
class="org.springframework.web.servlet.mvc.multiaction.ParameterMethodNameResolver">
<property name="paramName">
<value>param</value>
</property>
</bean>
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.
23 / 26
Nel nostro esempio:
ospiteController invocherà il metodo listOspite per processare la request. In seguito si
vedranno i dettagli di codice e le caratteristiche che devono avere i metodi del controller per
poter gestire le request.
4) Il controller deve restituire un oggetto di tipo ModelAndView che contiene i dati restituiti
dall'elaborazione della request e la vista che deve essere mostrata all'utente. NOTA: a
questo punto abbiamo visto tutti i componenti del pattern MVC: il Controller e ora la classe
ModelAndView
5) <passo view interceptor>
Rimane da esplorare l'ultima parte del “cammino” della request nel framework Spring MVC, la
parte relativa alla visualizzazione. Le View altro non sono che le pagine JSP o HTML finali che
vedrà l'utente. Il View Resolver è invece un componente configurato ancora una volta nel file di
contesto:
<bean id="viewResolver"
class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="viewClass">
<value>org.springframework.web.servlet.view.JstlView</value>
</property>
<property name="prefix">
<value>/WEB-INF/jsp/</value>
</property>
<property name="suffix">
<value>.jsp</value>
</property>
</bean>
Configurazione del View Resolver
Ancora non ci siamo addentrati nel codice, tuttavia basta sapere che quando all'interno di una
classe Controller costruiamo la vista lo facciamo semplicemente specificando la pagina web che
desideriamo. Il bean che vediamo in figura dichiara che la dispatch servlet nel restituire all'utente la
pagina indicata la andrà a cercare per default alla posizione /WEB-INF/jsp/ della nostra
applicazione web e le assegnerà in automatico il prefisso jsp.
Data quindi la struttura della nostra applicazione
24 / 26
per richiamare la pagina listOspite.jsp nel codice è sufficiente scrivere solo listOspite(passo 5 e
6).
3.5 Codice di ospiteController
Come anticipato ospiteController possiede il metodo listOspite, richiamato per recuperare
l'elenco degli ospiti e visualizzarli nella pagina listOspite.jsp.
public ModelAndView listOspite(HttpServletRequest request,
HttpServletResponse response) {
List elencoOspiti = ospiteManager.getOspiti(0, 100);
return new ModelAndView("listOspite", "elencoOspiti", elencoOspiti);
}
Metodo listOspite
L'elenco degli ospiti è passato alla pagina listOspite.jsp come variabile di request nominata
elencoOspiti.
25 / 26
Appendice: note sulla configurazione
26 / 26

Progetto Jug4Tenda

Transcript

Documenti analoghi

Corso sul linguaggio Java

Alfredo Massai - Ordine ingegneri della Provincia di Roma

Integrazione Macchina virtuale Java versione 1.5.0_16 del 23

Il linguaggio Java

Scarica il programma del corso - Associazione Pianeta Formazione

Ricerca di personale: n. 18 Java Developer Profilo posizione

Istruzioni per poter utilizzare la Ricerca avanzata con - Edit 16

javadoc - Pearson