Spring 3. Traversi Simone

Transcript

1 Spring 3 Traversi Simone 29 gennaio 2010

2 Indice Introduzione iv 0.1 Panoramica iv 0.2 Le innovazioni iv 0.3 I moduli v I Core Technologies 1 1 Il contenitore IoC Creazione di un bean Congurazione di un bean Costruire una rete di oggetti Le collezioni I generics La stringa vuota e il null Inizializzazione Lazy Lo scope Ciclo di vita Estensione del container BeanPostProcessor BeanFactoryPostProcessor BeanFactory Ereditarietà Usare i le.properties Uso delle annotation Rilevazione automatica dei componenti Uso dei ltri per uno scanning customizzato Internazionalizzazione con MessageSource Validazione Introduzione L'interfaccia Validator Gestione di controlli più complessi Gestione dei messaggi d'errore tramite messagesource Validazione di una rete di bean i

3 INDICE ii 3 Spring Expression Language (SpEL) Introduzione Panoramica sulle caratteristiche Valutazione delle espressioni usando l'interfaccia Expression di Spring L'interfaccia EvaluationContext Supporto delle espressioni alla denizione dei bean Reference del linguaggio Spring AOP Introduzione Concetti dell'aop Capacità e obiettivi di Spring AOP AOP Proxies AOP Abilitare il supporto Dichiarare un aspetto Dichiarare un pointcut Indicatori supportati per i Pointcut Combinare le espressioni dei pointcut Condividere le denizioni dei pointcut in comune Alcuni esempi Dichiarare un advice Before After returning After throwing After (nally) Around Gestione dei parametri Priorità Introduction Modello di instanziazione di un aspetto Esempio AOP con XML Dichiarare un aspetto Dichiarare un pointcut Dichiarare un advice Before After returning After throwing After (nally) Around Gestione dei parametri Introduzioni Modello di instanziazione di un aspetto Advisors Esempio Scegliere lo strumento per gestire l'aop Spring AOP o AspectJ? o XML?

4 INDICE iii 4.5 Il meccanismo dei proxy Capire i proxy AOP Creazione programmatica dei 60 II Data Access 61 5 Gestione delle transazioni Vantaggi del supporto di Spring alla gestione delle transazioni Transazioni globali Transazioni locali Modello di programmazione di Spring Comprendere l'astrazione delle transazioni di Spring Gestione dichiarativa delle transazioni Comprendere l'approccio dichiarativo Esempio Rollback Congurazione dierenti per bean dierenti <tx:advice/> Congurazione Propagazione delle transazioni Required RequiresNew Nested Advise per le transazioni Gestione programmatica delle transazioni Usare il PlatformTransactionManager Gestione dichiarativa Vs gestione programmatica

5 Introduzione Questo documento ha lo scopo di fornire una guida semplice e immediata, ma non esaustiva, all'utilizzo del framework Spring. Il motivo che mi ha spinto alla composizione di questo documento risiede nella scarsissima presenza di materiale in italiano sull'argomento. Ci tengo a precisare che questa guida non presenta tutti gli argomenti presenti sulle reference uciali, ma solo una selezione, eettuata sulla base dell'eettiva utilità che io ho rilevato su certe funzionalità. Tanto per citare uno dei grandi esclusi, la funzionalità dell'autowiring non sarà trattata, poichè la ritengo una funzionalità che se da una parte semplica un pochino il le di congurazione di Spring, dall'altra rischia di introdurre imprecisione nella struttura dell'applicazione che si realizza. Tale imprecisione, se non ben controllata, può portare a un cattivo funzionamento. Tuttavia, saltare questo argomento non toglie nulla allo studio del framework, poichè lo stesso tipo di funzionalità (ma senza imprecisioni) può essere ottenuta con altri strumenti che invece saranno trattati. In ogni caso, per qualsiasi approfondimento si consiglia di utilizzare la documentazione uciale in lingua inglese, disponibile all'indirizzo: La versione a cui questo documento si riferisce è la Panoramica Spring è un framework opensource per lo sviluppo di applicazioni su piattaforma Java [Wikipedia]. Il suo scopo è quello di rendere lo sviluppo di applicazioni enterprise più semplice e più veloce, abbattendo quindi i costi di produzione. La prima versione venne scritta da Rod Johnson, nel Giugno 2003 e sotto Licenza Apache. Il primo rilascio, la versione 1.0, risale al Marzo Spring nasce per fornire agli sviluppatori un'alternativa più semplice agli EJB 2.0, lasciando al tempo stesso una maggiore libertà. In questo è stato ampiamente riconosciuto come un ottimo risultato. 0.2 Le innovazioni Uno dei meriti di questo framework è stato quello di rendere popolari alcune tecniche prima di esso poco note, come l'inversion Of Control e il paradigma di programmazione orientata agli aspetti. Tipicamente un'applicazione Java è composta da un certo numero di componenti, gli oggetti, che collaborano l'uno con l'altro per ottenere il comportamento desiderato. Tali oggetti sono pertanto legati da dipendenze. Il linguaggio Java ha sempre lasciato gli sviluppatori molto liberi di progettare l'architettura delle applicazioni con assoluta (forse troppa) libertà. Per questo motivo nel corso del iv

6 INTRODUZIONE v tempo sono nati una vasta gamma di patterns (Factory, Builder, Abstract Factory, Decorator, Service Locator) comunemente riconosciuti ed accettati dall'industria del software. Questo è stato sicuramente un bene, ma i pattern sono solo questo: dei best pratices. Il modulo dell'ioc (Inversion of Control), come si vedrà in seguito, formalizza questi concetti, fornendo una infrastruttura che guida lo sviluppatore nella costruzione dell'applicazione, fornendogli tutti gli strumenti necessari per poter applicare i suddetti patterns. La programmazione orientata agli aspetti è un paradigma di programmazione basato sulla creazione di entità software, gli aspetti, che sovrintendono alle interazioni fra oggetti nalizzate ad eseguire un compito comune. Il vantaggio rispetto all'approccio tradizionale ad oggetti consiste nel non dover implementare separatamente in ciascun oggetto il codice necessario ad eseguire questo compito comune [Wikipedia]. Tipici esempi di responsabilità 'spalmate' su molteplici oggetti sono il log delle operazioni o la gestione della prolazione. Entrambi questi concetti saranno approfonditi più avanti. 0.3 I moduli In realtà chiamarlo framework è forse riduttivo, poichè Spring è composto da una vasta gamma di moduli, ognuno dei quali è un framework a se stante. L'aspetto interessante è che ognuno di questi moduli lavora in maniera indipendente dagli altri. Questo permette di integrare nella propria applicazione tutti e soli i moduli di interesse. Non siamo quindi costretti ad un approccio del tipo o tutto o niente. Tali moduli si possono raggruppare in base alle loro caratteristiche principali: Core Container, Data Access/Integration, Web, AOP, Instrumentation, Test. L'organizzazione di tali gruppi è visibile chiaramente nella gura 1. Figura 1: Architettura di Spring

7 INTRODUZIONE vi Nei capitoli che seguiranno verrano descritti questi moduli uno per uno.

8 Parte I Core Technologies 1

9 Capitolo 1 Il contenitore IoC E' probabilmente uno degli aspetti in cui Spring si è mostrato veramente innovativo. Per usufruire di tale servizio è necessario importare nel proprio progetto i due les jar org.springframework.beans e org.springframework.context. Molto spesso nelle nostre applicazioni, capita che un oggetto A debba usare il metodo di un oggetto B. Quando questo succede, tipicamente l'oggetto A deve prima di tutto creare un'istanza di B. Questa operazione è possibile tramite l'uso dell'operatore new: // classe B public class B { public void esegui() { System.out.println("Ciao Mondo!"); // classe A public class A { public static void main(string[] args) { B b = new B(); b.esegui(); Con l'operatore new noi stiamo chiedendo l'istanziazione della classe B. Ovvero la classe A chiede alla JVM un'istanza della classe B, come rappresentato in gura 1.1. new A JVM Figura 1.1: Creazione di un bean L'IoC parte dall'idea di inframezzare tra la classe A e la JVM un terzo componente, che chiameremo IOC, che si propone come intermediario. Il passaggio, com'è visibile in gura 1.2, sarà quindi: A chiede a IOC di chiedere a JVM un'istanza della classe B. 2

10 CAPITOLO 1. IL CONTENITORE IOC 3 Figura 1.2: Inversion of Control Da qui, il concetto di 'inversione del controllo': non siamo più 'noi' a chiedere un'istanza, ma è qualcun altro che la chiede (certo, sulla base comunque delle nostre istruzioni) e ce la restituisce. Ma perchè introdurre un'indirezione? L'idea di introdurre un intermediario, in realtà, non è poi cosi strana. In eetti, nelle attuali applicazioni, molto spesso la creazione dei beans è adata a classi (di solito statiche) preposte a questo compito, nel rispetto del pattern factory. Nell'esempio in gura 1.3 le classi del business che hanno bisogno di utilizzare classi dao, ne chiedono le istanze al modulo ServiceFactory. Il vantaggio è quello di centralizzare il concetto di creazione (e soprattutto congurazione) dei beans all'interno di un'unica classe, anchè il problema possa essere gestito più agilmente. I vantaggi di questo approccio saranno meglio evidenziati più avanti. Business DAO ServiceFactory Figura 1.3: Esempio di implementazione del pattern factory Supponendo di adottare una soluzione di questo tipo, il nostro codice diventerebbe: // Factory public abstract class BeansFactory { public static B getb() { return new B(); // classe A public class A {

11 CAPITOLO 1. IL CONTENITORE IOC 4 public static void main(string[] args) { B b = BeansFactory.getB(); b.esegui(); 1.1 Creazione di un bean L'idea di IoC è quindi una formalizzazione di una tecnica già presente da diversi anni nell'ingegneria del software. Tale modulo ci mette quindi a disposizione una factory già pronta per l'uso alla quale dobbiamo solo dare le istruzioni per la creazione dei beans. Come in tutti i framework, tale congurazione avviene tramite le xml. Quello che segue è il codice d'esempio del le spring-cong.xml: <?xml version="1.0" encoding="utf-8"?> <beans xmlns=" xmlns:xsi=" xsi:schemalocation=" <!-- Definizione dei beans --> <bean id="pippo" class="esempio.b" /> </beans> Il tag usato per la denizione dei beans è <bean>. Ogni beans andrà denito dentro un proprio tag di questo tipo. Tra i vari attributi che è possibile settare, due sono obbligatori: id, con il quale deniamo il nome che decidiamo di assegnare al bean in questione (in questo caso pippo); class, con il quale specichiamo al container qual è, all'interno del nostro progetto, la classe che dovrà essere utilizzata per l'implementazione di pippo, completa di package in cui tale classe si trova. Vediamo a questo punto come cambia il codice all'interno della nostra classe A. // classe A public class A { public static void main(string[] args) { ApplicationContext context = new ClassPathXmlApplicationContext(new String[] {"spring-config.xml"); B b = (B) context.getbean("pippo"); b.esegui(); ApplicationContext è l'interfaccia che ci permette di comunicare con il container IoC e utilizzare i servizi che mette a disposizione. Per poter usufruire di tali servizi creiamo l'oggetto context (che quindi è di tipo ApplicationContext), passandogli il le di congurazione a cui deve fare riferimento, e in cui nello specico abbiamo denito il bean pippo. L'argomento della funzione ClassPathXmlApplicationContext() è un array di stringhe poichè possono essere passati più le.xml.

12 CAPITOLO 1. IL CONTENITORE IOC 5 A questo punto possiamo chiedere al container di restituirci un'istanza del bean che abbiamo chiamato 'pippo', tramite il metodo getbean(string nome). Tale metodo è sovraccarico. In questa specica denizione, accetta come parametro una stringa (il nome del bean che vogliamo). Restituisce un object, e questo ci costringe ad un cast. Se vogliamo evitare il cast possiamo anche scrivere: B b = context.getbean("pippo", B.class); Avendo passato la classe B tra i parametri, il cast non è necessario. 1.2 Congurazione di un bean Naturalmente, se il ruolo dell'intermediario fosse solo quello di creare oggetti, sarebbe piuttosto complicato capirne l'utilità. Molto spesso capita che un bean, prima di essere usato, debba essere congurato. Potrebbe essere il caso di un DAO, che prima di essere usato devono essere settati i suoi parametri per la connessione ad un db. In generale, ogni oggetto il cui comportamento è determinato dal valore dei suoi attributi, deve essere congurato prima di essere usato. In un caso come quello sopra descritto, alla creazione di un bean, dovrebbero seguire un elenco di chiamate ai suoi metodi set() per settare tutti gli attributi del bean, o in alternativa, creare un costruttore ad hoc per poterlo fare. Il modulo IoC di Spring, consente di settare i parametri di congurazione direttamente dentro il le di congurazione. Supponiamo che la classe B sia fatta cosi: // classe B public class B { private String stringa; public void esegui() { System.out.println(this.stringa); // metodi set() e get()... In questo modo, il metodo esegui() scrive sulla console la stringa con cui in quel momento è stato settato l'oggetto. Il le di congurazione di Spring a questo punto potrebbe diventare questo: <?xml version="1.0" encoding="utf-8"?> <beans xmlns=" xmlns:xsi=" xsi:schemalocation=" <!-- Definizione dei beans --> <bean id="pippo" class="esempio.b"> <property name="stringa" value="ciao Mondo!" /> </bean>

13 CAPITOLO 1. IL CONTENITORE IOC 6 </beans> E' stato aggiunto un nuovo nodo, interno a <bean> che è <property>. Con questo tag è possibile elencare tutti gli attributi che si vogliono congurare contestualmente alla creazione del bean. Ogni attributo viene identicato con l'attributo name, valorizzato con il nome con cui è stato chiamato all'interno della classe B. Il suo valore viene settato con l'attributo value. Questa denizione è anche dotata di un meccanismo automatico di conversione dei valori. Se per esempio scrivessimo: <!-- bean che rappresenta un punto nel piano --> <bean id="origine" class="esempio.punto"> <property name="x" value="0.0" /> <property name="y" value="0.0" /> </bean> il sistema, conoscendo il tipo di x e y, sa in automatico che i valori '0.0' sono numeri e come tali li convertirà. Se x fosse di tipo String, tratterebbe '0.0' come una stringa. La classe A non subisce alcuna modica. Una chiamata del tipo: B b = context.getbean("pippo", B.class); restituirebbe un'istanza di B già congurata cosi come specicato nel le spring-cong.xml. E' facile capire come questo meccanismo renderebbe più semplice, per fare un esempio, l'uso di un DAO. Il le spring-cong.xml potrebbe contenere un frammento del tipo. <!-- dao --> <bean id="dao" class="esempio.classedao"> <property name="url" value="jdbc:mysql://localhost:3306/mydb" /> <property name="driver" value="com.mysql.jdbc.driver" /> <property name="username" value="admin" /> <property name="password" value="admin" /> </bean> In questo modo, chiedere al container un'istanza di 'dao' restituirebbe una dao già congurato e pronto all'uso. Ovviamente è possibile descrivere più congurazioni diverse per lo stesso bean. Potrei per esempio creare più di una congurazione diversa per ClasseDAO, chiamandone una o l'altra in funzione dello specico DB da utilizzare. Non è possibile, però, avere due bean con lo stesso id. Anchè questo meccanismo possa funzionare, è necessario che siano stati creati i metodi set() di tutti gli attributi che Spring dovrà settare. Il fatto che sia il container a settare direttamente gli attributi, prende il nome di Direct Injection (iniezione diretta, DI). 1.3 Costruire una rete di oggetti E se l'attributo di un bean è un riferimento ad un altro oggetto? Un'applicazione, tipicamente, è strutturata come una rete di oggetti, più o meno tta, che collaborano tra loro. Ogni oggetto, quindi, svolge il suo compito usandone altri.

14 CAPITOLO 1. IL CONTENITORE IOC 7 Uno degli aspetti più utili del modulo IoC di Spring è che il meccanismo di DI funziona anche nel caso in cui l'attributo da settare è un riferimento ad un altro oggetto! Vediamo un esempio... Supponiamo di avere la seguente situazone: // classe B public class B { private String stringa; public void esegui() { System.out.println(this.stringa); // classe A public class A { private B b; public void esegui() { this.b.esegui(); // classe Main public class Main { public static void main(string[] args) { ApplicationContext context = new ClassPathXmlApplicationContext( new String[] {"spring-config.xml"); A a = context.getbean("pippo", A.class); a.esegui(); In questo esempio, l'oggetto A, per eseguire il metodo esegui() ha bisogno di utilizzare l'oggetto B. Il le di congurazione di Spring diventa: <!-- bean A --> <bean id="pippo" class="esempio.a"> <property name="b" ref="pluto" /> </bean> <!-- bean B --> <bean id="pluto" class="esempio.b" > <property name="stringa" value="ciao Mondo!" /> </bean> Qui vediamo un altro uso del tag <property>. Poichè la variabile b è un riferimento ad un altro oggetto, al posto dell'attributo value si usa l'attributo ref. Tale attributo permette di

15 CAPITOLO 1. IL CONTENITORE IOC 8 dire al container che quella variabile va fatta riferire ad un altro bean. Il valore dell'attributo ref è l'id che viene denito per un bean. Nel nostro caso specico, quando verrà fatta la chiamata A a = context.getbean("pippo", A.class); verrà creata un'istanza di 'pluto' e poi 'iniettata' nella variabile b del bean 'pippo'. E' facile immaginare come con questo meccanismo sia possibile tirare su con una semplice istruzione una rete di oggetti complicata quanto si vuole. Il programmatore deve solo opportunamente congurarla all'interno del le spring-cong.xml. 1.4 Le collezioni Può capitare, naturalmente, che un attributo di un oggetto sia una collezione (list, map, set o properties). In tal caso la sintassi nel spring-cong.xml può essere la seguente: <bean id="oggettocomplicato" class="progetto.complexobject"> <!-- Per le liste --> <property name="lista"> <list> <!-- Inserisco l'elemento per valore --> <value>elemento qualunque</value> <!-- Oppure lo inserisco per riferimento --> <ref bean="miodatasource" /> </list> </property> <!-- Mappa --> <property name="mappa"> <map> <!-- Elemento inserito per valore --> <entry key="elemento" value="una stringa qualunque"/> <!-- Elemento inserito per riferimento --> <entry key ="riferimento" value-ref="miodatasource"/> </map> </property> <!-- Set --> <property name="set"> <set> <value>una stringa qualunque</value> <ref bean="miodatasource" /> </set> </property> <bean> I generics Dalla Java 5 in poi, è possibile utilizzare le collezioni tipizzate. Utilizzando il meccanismo di DI per settare una collezione all'interno di un bean, possiamo trarre vantaggio dal meccanismo di conversione di tipi di Spring. Ad esempio:

16 CAPITOLO 1. IL CONTENITORE IOC 9 public class Pippo { private Map<String, Float> conti; public void setconti(map<string, Float> conti) { this.conti = conti; <beans> <bean id="pippo" class="x.y.pippo"> <property name="conti"> <map> <entry key="uno" value="9.99"/> <entry key="due" value="2.75"/> <entry key="sei" value="3.99"/> </map> </property> </bean> </beans> Le stringhe '9.99', '2.75' e '3.99' verranno automaticamente convertite in Float. 1.5 La stringa vuota e il null Spring tratta un argomento vuoto come una stringa vuota. Scrivendo: <bean id="esempio" class="esempi.prova"> <property name=" " value="" /> </bean> l'attributo verrà settato come se avessimo lanciato il seguente comando: set (""); Se si vuole invece considerare il valore null, si deve scrivere: <bean id="esempio" class="esempi.prova"> <property name=" "> <null/> </property> </bean> 1.6 Inizializzazione Lazy L'ApplicationContext tipicamente eettua una pre-istanziazione dei bean singletons in fase di inizializzazione dell'applicazione. Questo comportamento è molto comodo perchè permette di individuare alcuni errori subito piuttosto che dopo qualche ora o addirittura dopo qualche giorno. Tuttavia, qualora non si desideri questo comportamento, è possibile chiedere esplicitamente al container un'inizializzazione di tipo lazy di uno o più bean. <bean id="lazy" class="com.foo.expensivetocreatebean" lazy-init="true"/> <bean name="not.lazy" class="com.foo.anotherbean"/> Nel caso del bean chiamato lazy, questo verrà istanziato solo quando verrà esplicitamente indicato al container.

17 CAPITOLO 1. IL CONTENITORE IOC Lo scope Lo scope di un bean rappresenta l'arco di tempo in cui il bean deve essere utilizzabile e al di fuori del quale non lo deve essere. Spring supporta cinque diversi scope, tre dei quali sono disponibili solo in contesti Web. La tabella 1.1 riassume gli scope disponibili: scope descrizione singleton il bean è l'unico del suo tipo all'interno del container prototype esiste un bean per ogni istanza creata request il bean esiste solo nell'ambito di una singola richiesta HTTP session il bean esiste nell'ambito di un'intera HTTP Session globalsession il bean esiste nell'ambito di una HTTP Session globale Tabella 1.1: scope dei bean Per la denizione dello scope di un bean, si utilizza l'attributo scope del tag <bean>: <bean id="pippo" class="esempi.pippo" scope="prototype" /> I valori ammessi sono quelli espressi in tabella 1.1. Quando lo scope di un bean viene denito singleton, il container memorizza l'istanza dell'oggetto all'interno di una cache. Ad ogni successiva richiesta di quel bean, il container restituirà sempre la stessa istanza. Questo tipo di scope viene adottato da Spring di default. Quando invece lo scope viene denito prototype, il container ad ogni richiesta del bean, ne crea un'istanza nuova, sovrascrivendo quella vecchia. Gli altri tre scope rispondono alle stesse regole delle web application. Spring mette inoltre a disposizione un sistema per creare scopes personalizzati (vedi 3.5 delle reference). 1.8 Ciclo di vita Spring consente di specicare quali azioni debbano essere svolte durante l'inizializzazione di un bean, cosi come anche le precedure da eseguire prima della sua distruzione. Per quanto riguarda l'inizializzazione, è possibile denire all'interno del bean il metodo init() invocandolo poi in fase di congurazione con l'attributo init-method. Ad esempio: public class Pippo { //... public void init() { // Inizializzazione dell'oggetto... <bean id="pippo" class="esempi.pippo" init-method="init" /> Quando al container viene chiesta un'istanza di pippo, subito dopo la sua creazione verrà invocato il metodo init(). Lo stesso discorso vale anche per la fase di distruzione di un bean. In questo caso l'attributo da usare è destroy-method. Ad esempio:

18 CAPITOLO 1. IL CONTENITORE IOC 11 public class Pippo { //... public void cleanup() { // Distruzione dell'oggetto... <bean id="pippo" class="esempi.pippo" destroy-method="cleanup" /> In questo modo, prima della distruzione del bean pippo verranno eseguite tutte le operazioni all'interno del metodo cleanup() (ad esempio la chiusura delle connessioni di un dao). 1.9 Estensione del container Vediamo ora alcune funzionalità che ci permettono di estendere le funzionalità del container BeanPostProcessor L'IoC permette di poter estendere alcune funzionalità sul controllo del ciclo di vita dei bean, facendo uso di apposite interfacce. Una di queste è la BeanPostProcessor. Tale interfaccia è mostrata di seguito: public interface BeanPostProcessor { Object postprocessbeforeinitialization(object bean, String name) throws BeansException; Objcet postprocessafterinitialization(object bean, String name) throws BeansException; E' suciente scrivere una classe che implementi questa interfaccia e dichiararla come bean all'interno del le di congurazione di spring. A questo punto, prima della fase di inizializzazione di ogni bean verrà richiamato il metodo postprocessbeforeinitialization(...) e dopo l'inizializzazione il metodo postprocessafterinitialization(...). L'esempio molto semplice che segue mostra un BeanPostProcessor che chiama il metodo tostring() ogni volta che viene creato un nuovo bean. public class MioBeanPostProcessor implements BeanPostProcessor { // ritorno il bean appena istanziato così com'è public Object postprocessbeforeinitialization(object bean,string beanname) throws BeansException { return bean; public Object postprocessafterinitialization(object bean,string beanname) throws BeansException { System.out.println( "Bean '" + beanname + "' creato : " + bean.tostring() ); return bean;

19 CAPITOLO 1. IL CONTENITORE IOC 12 A questo punto è suciente dichiararlo all'interno del spring-cong.xml: <bean class="esempi.miobeanpostprocessor"/> Da notare che questo bean non ha l'attributo id. Immaginando una situazione del tipo // classe Punto public class Punto { private int x; private int public String tostring() { return "x="+this.getx()+" y="+this.gety();... // configurazione per Spring <bean id="punto" class="esempi.punto"> <property name="x" value="1" /> <property name="y" value="3" /> </bean> il metodo main seguente public static void main(final String[] args) throws Exception { ApplicationContext context = new ClassPathXmlApplicationContext( new String[] {"spring-config.xml"); Punto p = context.getbean("punto"); produrrebbe un output del tipo Bean 'punto' creato : x=1 y= BeanFactoryPostProcessor Esiste anche il concetto di BeanFactoryPostProcessor che attraverso il metodo postprocess- BeanFactory(...) permette di aggiungere del comportamento dopo che il container ha caricato le denizioni dei beans, ma prima che gli stessi siano istanziati. Non va quindi a inserirsi nel ciclo di vita dei beans, ma in quello dello stesso container. L'interfaccia è la seguente: public interface BeanFactoryPostProcessor { public void postprocessbeanfactory( ConfigurableListableBeanFactory beanfactory) throws BeansException;

20 CAPITOLO 1. IL CONTENITORE IOC 13 Anche in questo caso è suciente creare un bean che implementi questa interfaccia e denirne la congurazione all'interno dello spring-cong.xml BeanFactory E' possibile implementare l'interfaccia org.springframework.beans.factory.factorybean per tutti quegli oggetti che sono essi stessi delle factory. Tale interfaccia è da considerare come un'occasione per aggiungere funzionalità logiche di istanziazione al container IoC. Qualora si abbia del codice molto complesso per l'inizializzazione che rimane meglio esprimere direttamente in java invece che con moltissimo codice XML, è possibile creare una propria FactoryBean, scrivere l'inizializzazione all'interno di questa classe e inne integrare tale classe all'interno del container. Questa interfaccia provvede ai seguenti tre metodi: ˆ Object getobject(): ritorno un'istanza dell'oggetto che questa factory crea; ˆ boolean issingleton(): ritorna true se questa FactoryBean ritorna un singleton, false altrimenti; ˆ Class getobjecttype(): ritorna il tipo ritornato da getobject() o null se il tipo non è noto a priori; ApplicationContext estende questa interfaccia Ereditarietà La denizione di un bean può comprendere la congurazione di molte informazioni. La denizione di un bean glio eredita tutte queste informazioni. Inoltre può anche sovrascrivere alcuni valori o aggiungerne di nuovi, in base alle necessità. Questo tipo di congurazione è possibile tramite l'attributo parent del tag <bean>, come mostrato nell'esempio seguente: <bean id="inheritedtestbean" abstract="true" class="esempi.testbean"> <property name="name" value="parent"/> <property name="age" value="1"/> </bean> <bean id="inheritswithdifferentclass" class="esempi.derivedtestbean" parent="inheritedtestbean" init-method="initialize"> <property name="name" value="override"/> <!-- Il valore 1 sulla proprietà age viene ereditato dal padre --> <!-- l'attributo name invece viene sovrascritto --> </bean> La denizione del bean glio usa la classe dalla denizione del padre, se non ne è stata specicata nessuna, ma può anche sovrascriverla. In quest'ultimo caso, la classe del glio dev'essere compatibile con quella del padre e deve accettare i valori delle proprietà del genitore. La denizione di un bean glio eredita i valori degli argomenti del costruttore, i valori delle proprietà e i metodi dal padre, con in più la possibilità di aggiungere nuovi valori. Ogni metodo di inizializzazione, di distruzione e/o setting dei metodi factory statici che si specica eettuerà un override dei corrispondenti deniti nel genitore. Ciò che rimane viene sempre

21 CAPITOLO 1. IL CONTENITORE IOC 14 preso dalla denizione del glio: depends on, autowire mode, dependency check, singleton, scope e lazy-init. L'esempio precedente marca esplicitamente la denizione del bean genitore come astratto, usando l'attributo abstract. Se la denizione del padre non specica nessuna classe, tale denizione dev'essere marcata necessariamente come astratta, come segue: <bean id="inheritedtestbeanwithoutclass" abstract="true"> <property name="name" value="parent"/> <property name="age" value="1"/> </bean> <bean id="inheritswithclass" class="esempi.derivedtestbean" parent="inheritedtestbeanwithoutclass" init-method="initialize"> <property name="name" value="override"/> <!-- Il valore 1 sulla proprietà age viene ereditato dal padre --> <!-- l'attributo name invece viene sovrascritto --> </bean> Il bean genitore non può essere istanziato da solo, perchè è incompleto, essendo stato esplicitamente marcato come astratto. Quando una denizione è astratta come questa, viene utilizzata esclusivamente come template che serve come genitore per la denizione di altri bean. Se si prova a richiedere al container un'istanza di tale bean, con il metodo getbean(), viene ritornato un errore. Allo stesso modo, il metodo preinstantiatesingletons() del container ignora le denizioni dei bean settati come astratti Usare i le.properties Abbiamo visto come sia possibile costruire il le di congurazione di Spring in modo tale che contestualmente alla denizione di un bean si possano anche denire i valori dei suoi attributi. Tuttavia, scrivere esplicitamente i valori all'interno del le.xml può risultare poco comodo. Risulta sicuramente più pratico raccogliere i valori in un le di properties. Un le di properties è un semplice le di testo, con estensione.properties, e che è strutturato come una mappa: chiave = valore Quello che segue ne è un esempio: url = jdbc:mysql://localhost:3306/mydb driver = com.mysql.jdbc.driver username = admin password = admin x = 1 y = 3 Tali le sono molto usati, per esempio, per passare i dati di congurazione di un db, oppure per gestire la localizzazione di un sito (un le di properties per ogni lingua, le chiavi sono sempre le stesse, ma cambiano i valori), ecc. Per catturare tali valori all'interno del le spring-cong.xml si usa la seguente sintassi:

22 CAPITOLO 1. IL CONTENITORE IOC 15 <!-- Definizione file properties --> <bean class="org.springframework.beans.factory.config.propertyplaceholderconfigurer"> <property name="locations" value="classpath:/proprieta.properties"/> </bean> <!-- oppure con la seguente espressione --> <context:property-placeholder location="classpath:/proprieta.properties"/> <!-- Definizione dei beans --> <bean id="dao" class="esempiospring.miodao"> <property name="url" value="${url" /> <property name="driver" value="${driver" /> <property name="username" value="${username" /> <property name="password" value="${password" /> </bean> <bean id="punto" class="esempiospring.punto"> <property name="x" value="${x" /> <property name="y" value="${y" /> </bean> 1.12 Uso delle annotation A partire dalla versione 1.5 di Java, sono supportate ucialmente le annotation. Spring permette di realizzare la propria congurazione anche tramite questo strumento. Si applica ai metodi setter, come nel seguente esempio: public class SimpleMovieLister { private MovieFinder public void setmoviefinder(moviefinder moviefinder) { this.moviefinder = moviefinder; //... Questa annotation semplicemente indica che l'attributo associato al metodo set() deve essere necessariamente popolato a tempo di congurazione, con un valore denito esplicitamente. In caso contrario, il container solleva prende il nome di un attributo e di dafault Spring interpreta questo valore come il nome di un bean da iniettare. public class SimpleMovieLister {

23 CAPITOLO 1. IL CONTENITORE IOC 16 private MovieFinder public void setmoviefinder(moviefinder moviefinder) { this.moviefinder = moviefinder; Se non viene specicato nessun nome, questo viene derivato dal nome dell'attributo o del metodo set() associato in base a dov'è stato applicato. Nell'esempio che segue verrà ricercato il bean chiamato 'moviefinder'. public class SimpleMovieLister { private MovieFinder public void setmoviefinder(moviefinder moviefinder) { this.moviefinder = moviefinder; Queste possono essere utilizzate per marcare i metodi di inizializzazione e di distruzione di un bean, come nell'esempio che segue: public class CachingMovieLister public void populatemoviecache() { // populates the movie cache upon public void clearmoviecache() { // clears the movie cache upon destruction... In questo modo non c'è bisogno di usare gli attributi init-method e destroy-method visti nel paragrafo Rilevazione automatica dei componenti Spring introduce, già a partire dalla versione 2.0, in concetto di stereotipo con usata per caratterizzare componendi di accesso ai dati (dao). Con Spring 2.5 vengono aggiunte due nuove per completare la classica architettura a tre livelli (accesso ai dati, servizi di business, controller dell'interfaccia). Inoltre introduce anche il che gli altri stereotipi estendono. Queste annotazioni possono essere usate in combinazione con un'altra funzionalità di Spring: la rilevazione automatica di componenti a partire dal classpath.

24 CAPITOLO 1. IL CONTENITORE IOC 17 Tale funzionalità può risultare utile in tutti quei casi in cui si vuole che il container distingua i bean in funzione del ruolo che svolgono all'interno del container, per esempio per una gestione diversicata dei log tra i vari strati dell'applicazione, oppure per gestire meglio il problema dell'autowiring. Per fare in modo che Spring esegua una scansione del classpath allo scopo di catalogare i bean che abbiamo marchiato, l'istruzione da inserire nel le di congurazione è la seguente: <context:component-scan base-package="org.example"/> dove l'attributo base-package specica il package da cui iniziare la ricerca. Questa scansione infatti non deve coinvolgere necessariamente tutta l'applicazione, ma anche solo una parte Uso dei ltri per uno scanning customizzato Di default, le classi o con delle annotazioni personalizzate sono i soli componenti rilevati. E' possibile modicare ed estendere questo comportamento semplicemente applicando dei ltri customizzati. Tali ltri possono essere inclusivi (prendi tutti i componenti che...) o esclusivi (prendi tutti i componenti tranne...) e devono essere dichiarati come nodi dell'elemento component-scan. Ogni ltro richiede il tipo e un'espressione. La tabella 1.2 riassume le opzioni dei ltri. Tipo di ltro Espressione d'esempio Descrizione annotation org.example.someannotation Un annotazione dev'essere presente al livello di tipo nel componente target assignable org.example.someclass Un classe (o interfaccia) che il componente target può estendere/implementare aspectj org.example..*service+ Un espressione di tipo AspectJ che deve matchare con il componente target regex org/.example/.default.* Un'espressione regolare che deve matchare con il nome della classe del componente target custom org.example.mycustomtypefilter Un'implementazione customizzata dell'interfaccia org.springframework.core.type.typefilter Tabella 1.2: Opzioni dei ltri L'esempio che segue mostra la congurazione XML ignorando tutti i tranne quelli che rispettano l'espressione regolare.*stub.*repository, ovvero il cui nome termina con Repository e il nome del package in cui sono contenuti termina con Stub. <beans> <context:component-scan base-package="org.example"> <context:include-filter type="regex" expression=".*stub.*repository"/>

25 CAPITOLO 1. IL CONTENITORE IOC 18 <context:exclude-filter type="annotation" expression="org.springframework.stereotype.repository"/> </context:component-scan> </beans> 1.14 Internazionalizzazione con MessageSource L'interfaccia ApplicationContext estende un interfaccia chiamata MessageSource e quindi provvede anche alla funzionalità di internazionalizzazione (i18n). I metodi deniti in questa interfaccia includono: ˆ String getmessage(string code, Object[] args, String default, Locale loc): Il metodo base utilizzato per recuperare un messaggio dal MessageSource. Se non viene trovato alcun messaggio, viene usato quello di default. ˆ String getmessage(string code, Object[] args, Locale loc): Fondamentalmente la stessa cosa del metodo precedente, ma con una dierenza: non è specicato alcun messaggio di default; se il messaggio non viene trovato, viene sollevata una NoSuchMessageException. ˆ String getmessage(messagesourceresolvable resolvable, Locale locale): Tutte le proprietà utilizzate nei metodi precedenti vengono wrappate in una classe chiamata Message- SourceResolvable. Quando viene caricato un ApplicationContext, viene automaticamente cercato un bean MessageSource denito nel contesto. Il bean deve avere il nome messagesource. Se tale bean viene trovato, tutte le chiamate dei metodi sopra elencati sono delegati al messagesource. Se invece non viene trovato, l'applicationcontext cerca un genitore che contenga un bean con lo stesso nome. Se lo trova lo usa come un MessageSource, altrimenti viene istanziato un DelegatingMessageSource vuoto, in grado di accettare chiamate ai metodi deniti sopra. L'uso del MessageSource è evidenziato dal seguente esempio: ˆ messaggi.properties benvenuto = Ciao Mondo!!! ˆ spring-cong.xml <beans> <bean id="messagesource" class="org.springframework.context.support.resourcebundlemessagesource"> <property name="basenames"> <list> <!-- Qui posso definire più file di properties. Per ora --> <!-- inserisco l'unico che ho che si chiama 'messaggi'. --> <value>messaggi</value> </list> </property> </bean> </beans> ˆ Main.java

26 CAPITOLO 1. IL CONTENITORE IOC 19 public class Main { public static void main(string[] args) { MessageSource resources = new ClassPathXmlApplicationContext("spring-config.xml"); String message = resources.getmessage("benvenuto", null, "Default", null); System.out.println(message); Eseguendo la classe Main, l'output sarà: Ciao Mondo!!! Se la voce benvenuto non fosse stata trovata all'interno del messaggi.properties, l'output sarebbe stato Default Questo meccanismo permette di eliminare qualunque stringa esplicitamente dichiarata all'interno del codice, sistemandole tutte in les appositi. Tale utilità risulta evidente proprio in fase di localizzazione. Supponendo per esempio di voler tradurre la nostra applicazione in inglese (en-gb), dovremo creare un le chiamato messaggi_en_gb.properties. Tipicamente la localizzazione è gestita dall'ambiente su cui gira l'applicazione. Supponendo per esempio di avere i seguenti les: ˆ messaggi.properties benvenuto = Ciao Mondo!!! ˆ messaggi_en_gb.properties benvenuto = Hello World!!! ˆ Main.java public class Main { public static void main(string[] args) { MessageSource resources = new ClassPathXmlApplicationContext("spring-config.xml"); // carico il file predefinito String message = resources.getmessage("benvenuto", null, "Default", null); System.out.println(message); // carico il file per la lingua inglese message = resources.getmessage("benvenuto", null, "Default", Locale.UK); System.out.println(message); L'output in questo caso sarà: Ciao Mondo!!! Hello World!!! La dierenza la fa l'ultimo parametro della funzione getmessage(...). Nel primo caso, non essendo specicato nessun valore, viene cercato in automatico il le messaggi (senza sussi). Nel secondo caso viene specicata la localizzazione inglese (Locale.UK), e quindi viene cercato lo stesso le ma con il susso per la lingue inglese (_en_gb).

27 Capitolo 2 Validazione 2.1 Introduzione La validazione, ovvero il controllo della validità dei valori con cui viene settato un bean o in generale vengono settati dei parametri, è un aspetto molto importante in ogni applicazione. Questa problematica diventa più critica quando i valori immessi provengono direttamente dall'utente. E' necessario quindi avere un meccanismo che consenta di controllare questo tipo di operazioni. Ci sono pro e contro nel considerare la validazione come parte della logica di business e Spring ore una soluzione per la validazione che non esclude nessuna delle due cose. In particolare la validazione ˆ non dovrebbe essere legata al layer web; ˆ dovrebbe essere semplice gestirne la localizzazione; ˆ dovrebbe essere possibile aggiungere qualunque validatore disponibile; Per assolvere a queste funzionalità, Spring propone l'interfaccia Validator. 2.2 L'interfaccia Validator Spring utilizza l'interfaccia Validator per consentire l'implementazione di meccanismi di validazione. Ogni validatore che si vuole costruire deve implementare tale interfaccia. Questi sono i metodi esposti: ˆ public boolean supports(class clazz); denisce su quali classi può agire il validatore. O meglio, data una classe passata come parametro restituisce true se il validatore in questione è stato scritto per poter validare quella classe. ˆ public void validate(object obj, Errors e); è il metodo che eettua la validazione sull'oggetto obj. Questo metodo fa anche uso dell'interfaccia Errors. Tutti gli errori rilevati durante l'esecuzione del metodo validate(...) verranno registrati all'interno di un apposito oggetto di tipo Errors. Vediamo il funzionamento di ciò di cui si è parlato nora con un esempio. Immaginiamo di avere un oggetto Indirizzo che racchiude tutte le informazioni per identicare univocamente un indirizzo nel mondo: 20

28 CAPITOLO 2. VALIDAZIONE 21 class Indirizzo { // attributi private String prefissovia; private String nomevia; private String numerocivico; private String cap; private String citta; private String provincia; private String nazione; // metodi set() e get()... // "via", "viale", "piazza", ecc. Per validare questo bean, abbiamo bisogno di un validatore ad hoc che, come descritto poco fa, deve implementare l'interfaccia Validator: public class IndirizzoValidator implements Validator { // Con questo metodo cosi definito, indichiamo che // questa classe valida SOLO gli oggetti Indirizzo public boolean supports(class clazz) { return Indirizzo.class.equals(clazz); // Metodo che realizza la validazione public void validate(object obj, Errors e) { ValidationUtils.rejectIfEmpty(e, "prefissovia", "required", "prefissovia è obbligatorio"); ValidationUtils.rejectIfEmpty(e, "nazione", "required", "nazione è obbligatorio"); ValidationUtils.rejectIfEmpty(e, "cap", "required", "cap è obbligatorio"); All'interno del metodo validate(...) vengono utilizzati i metodi statici della classe ValidationUtils. Il metodo rejectifempty(...), come dice il nome stesso, riuta (o, in altre parole, invalida la verica) il valore assegnato all'attributo pressovia di obj nel caso in cui tale attributo sia lasciato vuoto (ovvero con valore null). Il primo parametro è un riferimento all'oggetto di tipo Errors che raccoglierà tutte le informazioni circa gli errori rilevati; il secondo parametro si riferisce all'attributo di obj su cui viene eettuata la verica; il terzo parametro è un codice che rappresenta il tipo di errore. Tale codice è arbitrariamente scelto dallo sviluppatore (in questo caso è stato denito per semplicità all'interno della funzione, ma

29 CAPITOLO 2. VALIDAZIONE 22 sarebbe più corretto denirlo in un apposito le di costanti). L'ultimo parametro, che non è obbligatorio, è il messaggio d'errore di default. Secondo la logica utilizzata nell'esempio, un indirizzo non è considerato valido se il presso della via, la nazione e il cap non sono stati deniti. Per testare il nostro validatore, è suciente eseguire il seguente metodo main: public static void main(string[] args) { // creo un indirizzo Indirizzo i = new Indirizzo(); i.setnomevia("f. Ozanam"); i.setnumerocivico("44"); i.setcap(" "); // creo il validatore IndirizzoValidator iv = new IndirizzoValidator(); Errors errind = new BindException(i, i.getclass().getname()); // effettuo e gestisco la validazione iv.validate(i, errind); // controllo se ci sono stati errori if(errind.hasfielderrors()) { // mi faccio restituire una lista di errori rilevati sui campi List<FieldError> listacampi = errind.getfielderrors(); for (FieldError fe : listacampi) { System.out.println(fe.getDefaultMessage()); Vediamo di commentare il codice appena presentato. Tanto per cominciare viene creato un Indirizzo d'esempio, lasciando a null due dei tre campi richiesti come obbligatori. Viene poi creato il validatore. Abbiamo poi bisogno di un oggetto di tipo Errors. Naturalmente, trattandosi di un'interfaccia, niente ci impedisce di crearne uno nostro, ma Spring ne mette a disposizione alcuni già pronti. Nel nostro caso abbiamo usato un BindException. Non c'è un motivo particolare per aver scelto questo, se non che implementa Errors per un uso abbastanza standard. Da notare che questa classe estende Exception. Il costruttore di questo oggetto prende come parametri l'oggetto su cui si fa la validazione e il nome di tale oggetto. A questo punto possiamo chiedere al validatore di eettuare le veriche. Terminate queste operazioni, siamo ovviamente interessati a conoscere l'esito della validazione. Interroghiamo quindi l'oggetto Errors. Con il metodo hasfielderrors() verichiamo (ci restituisce un boolean) se sono stati rilevati errori sui controlli dei campi. In caso aermativo, con il metodo getfielderrors() ci facciamo restituire una lista di FieldError. Ognuno di questi oggetti contiene tutti i dettagli sugli errori rilevati sui campi. Nel nostro caso siamo interessati al messaggio di default per farcelo stampare sulla console. L'output di questo metodo produrrà il seguente risultato: prefissovia è obbligatorio nazione è obbligatorio Vediamo ora qualche osservazione di approfondimento.