Spring configuration e Spring Boot

Giocando con Spring Boot mi sono accorto che le configurazioni vengono fatte attraverso Spring Configuration.
Finora io, vecchio informatico, ho sempre configurato Spring tramite file Xml: questo approccio è sempre meno usato, proprio perché ormai, con l'avvento dei micro services, non si tende più a creare una singola applicazione monolitica dentro un web container (un file .war, tanto per capirsi).

Spring Configuration permette di esplicitare la configurazione via software: basta annotare le classi che costituiscono la nostra configurazione, ed automaticamente verranno caricati i beans corrispondenti. Qui il Javadoc

Una buona serie di esempi su come scrivere le varie configurazioni è disponibile qui. In particolare è interessante verificare come fare per iniettare le dipendenze.

Ora, quando si creano delle Controller, come si può fare a iniettare la dipendenza?
Le Controller in Spring Boot vengono automaticamente istanziate (qualsiasi classe che abbia l'annotation @Controller). In questo caso, come risolvere la dipendenza?
Si può usare l'annotation @Autowired in abbinamento con @Qualifier.
La annotazione @Autowired indica che la variabile verrà automaticamente valorizzata, e con @Qualifier si può esplicitare il nome del bean a cui associarla.
Se si omette il qualifier Spring cerca un bean con nome uguale a quello della variabile: qualora non lo trovi, o non sia del tipo corretto, lancia un'eccezione.
Per una panoramica su @Autowired e @Qaulifier si veda qui.

Migrating a Spring Web MVC application from JSP to AngularJS

https://spring.io/blog/2015/08/19/migrating-a-spring-web-mvc-application-from-jsp-to-angularjs

Spring e AngularJs - creare un'applicazione single-page sicura

Pur arrivando in ritardo sulle mie esigenze, quest'articolo è interessante.
Se l'avessi letto prima mi sarei risparmiato alcune noie.

http://spring.io/blog/2015/01/12/spring-and-angular-js-a-secure-single-page-application

Serializzare da e verso Xml

"Se i ragazzi di Spring lo hanno scelto, deve avere delle potenzialità"
Questo mi sono detto, quando ho provato ad usare XStream, una libreria per serializzare e deserializzare gli oggetti da XML.
E in effetti, le potenzialità ci sono. Innanzitutto perché xStream permette di serializzare e deserializzare senza uso di annotations, e questo fa davvero TANTO comodo. E poi perché permette, qualora il semplice mapping non bastasse, di scrivere dei converter in modo molto semplice (anzi se magari un po' lungo, visto che si può solo navigare l'albero dei nodi.

File Upload con Spring

A completamento del post precedente, come fare a gestire l'upload di un file via Spring?
Spring offre un automatismo eccezionale per la gestione del file uplaod: in un controller, basta dichiarare un parametro di tipo MultipartFile per poter subito avere il file a portata di mano (vedi qui)
C'è una sola cosa da ricordarsi (e che invece puntualmente mi scordo): dichiarare nei beans un multipartResolver. Senza questa dichiarazione le cose non funzionano.
Se, come nell'esempio precedente, la chiamata viene da un framework come Angularjs, attenti al parametro ritorno! Anche se non è necessario comunicare niente al client, non omettere mai la declaration @ResonseBody

REST client con Spring: un lavoro di tutto riposo.

Ho recentemente avuto la necessità di fare un client REST con Spring.

Niente di più facile!

La classe RestTemplate ha tutto quello che serve all'impresa! Basta implementare qualche metodo e il gioco è fatto!

Ricordate, RestTemplate, e non sarà più come prima.

Activiti o la BPM semplice

Era già un po' che guardavo Activiti, in cerca di un piccolo progetto su cui poterlo testare, e alla fine se ne è presentata la possibilità, quindi ho cominciato a mettere le mani in pasta.
Mi ci ero avvicinato perché jBPM di jBoss mi sembrava un po' troppo pesante, e stavo cercando qualcosa di più snello ma sempre aderente ai concetto del Business Process Management. Inoltre, recentemente Activiti è stato acquisito da Alfresco, per rimpiazzare il loro workflow manager.
Il primo impatto è stato ottimo: esiste un ottimo designer, integrato in Eclipse, che permette di creare in modo semplice i flussi. E' ben fatto, anche se ancora qualcosa non funziona perfettamente, e permette facilmente di creare i flussi e soprattutto di testarli con poco sforzo.
Ma quello che più mi ha ben impressionato è la facilità con cui il tutto si configura. Sia che si opti per distribuire il motore come applicazione web (activiti-explorer.war contiene sia il motore sia un front-end di gestione e "primo utilizzo") che lo si embeddi nel proprio stack (se si usa Spring per i propri progetti tutto va su in un istante) in un attimo l'ambiente è up-and-running. Configurare la base dati è una bazzecola, 4 linee nell'apposito file (tipo database, url, user e password) et voilà, il gioco è fatto.
Insieme ad activiti-explorer si trova activiti-rest, l'applicazione per esporre via Rest tutte le funzionalità, permettendo a qualsiasi applicazione esterna di interagire con la workflow engine. Per far lavorare in sinergia i 2 applicativi è sufficiente farli puntare alla stessa base dati, e il gioco è fatto.
Nel mio caso Rest è stato manna dal cielo, perché mi ha permesso l'interoperatività con altri applicativi.
Partendo praticamente a digiuno in materia, in 4 giorni sono riuscito a installare, configurare, creare un piccolo flusso per le mie esigenze, un client in .Net per alimentare i flussi ed uno in Java per il reporting. Niente male davvero!

Gestire il file Upload con Spring

Fare del file upload non è mai stata un'operazione facile, o comunque abbastanza automatica. Si deve creare una servlet e scodare il file dai parametri di request del form.
Usando Spring ho visto che è stato molto semplificato il file Upload, e l'operazione si incastra nel meccanismo della DispatcherServlet e dell'ApplicationContext.
In pratica nell'Application Context basta aggiungere un'istanza della classe org.springframework.web.multipart.commons.CommonsMultipartResolver
Questa classe, quando intercetta una post action con encoding attribute multipart/form-data, la gestisce e trasforma il file in un request parameter di tipo MultipartHttpServletRequest o MultipartFile
Così trasformata la request viene passata al controller, dichiarando come parametri di input il file e gli altri parametri dichiarati nella form.

Come migrare da Weblogic o Websphere a Tomcat

Questo articolo è interessante, più che per i tips di migrazione, per il confronto tra i vari Application Server ( e perché ho scoperto OpenEJB non si finisce mai di imparare)

Spring 3 e lo Unit Testing

Ho fatto qualche piccolo passo nello Unit Testing di Spring3
L'ho fatto con JUnit4, in modo da poter sfruttare le annotations.
Uno potrebbe dire: JUnit ha i "classici" eventi di SetUp e TearDown, si usano quelli per istanziare Spring e poi si fanno i test normalmente.
Non è una cattiva idea, peccato che i due eventi vengono lanciati prima e dopo ogni test, quindi per fare 5 test si istanzia e distrugge 5 volte il framework Spring.
E allora come si fa?
Si usa l'annotation @RunWith di JUnit4. Questa annotation permette di invocare, invece del runner standard, il runner specificato. Spring4, nel pacchetto di test, ha il runner SpringJUnit4ClassRunner, quindi l'annotation diventa

@RunWith(SpringJUnit4ClassRunner.class)

OK, e ora come si fa a caricare la configurazione?
Semplice, sempre con l'annotation, questa volta specifica del package Spring Test, @ContextConfiguration
Questa annotation permette di specificare, sia con path relativo che assoluto, quali files usare per i test.
A questo punto basta scrivere i nostri test e, prima che vengano lanciati, verrà lanciato il framework spring con la configurazione specificata.

Spring Security: personalizzare l'authentication provider

Abbiamo già visto come gestire la sicurezza con Spring Security.
Come avevamo visto il framework si basa su una logica di authentication-manager, authentication-provider. Ci sono già alcune implementazioni pronte: molto comoda è quella in memoria, specialmente per il testing.
Altra implementazione "comoda" è quella JdbcDao. Il limite di questa implementazione è che il db da cui pescare i dati deve per forza essere fatto in un certo modo, anche se si possono specificare le query da eseguire, ma la flessibilità non è al 100%.
Mi sono quindi detto: proviamo ad implementare il mio provider.
Devo implementare l'interfaccia AuthenticationProvider che ha un unico metodo authenticate
Il metodo deve verificare che l'utente si possa autenticare e restituisce un oggetto Authentication, che porta con se lo username e le GrantedAuthority a cui appartiene, praticamente i ruoli dell'utente.

Vediamo un po' di codice...

public Authentication authenticate(Authentication auth) throws AuthenticationException {
        String username = auth.getPrincipal().toString();
        String password = auth.getCredentials().toString();
        if (!"Andrea".equals(username))
            throw new BadCredentialsException("Nome Utente non valido!");
        if (!"Andrea".equals(password))
            throw new BadCredentialsException("Password Errata!");
        Collection gas = new ArrayList();
        GrantedAuthority ga = new AndreaGrantedAuthority("G1");
        gas.add(ga);
        UsernamePasswordAuthenticationToken result = new UsernamePasswordAuthenticationToken(username, password, gas);       
        return result;
    }


La cosa veramente da notare e che, lo confesso, mi ha un po' spiazzato, sono le prime 2 righe, cioè il reperimento di username e password.
Soprattutto la password non era lampante. Poi, studiando un po' di teoria, ho visto che siamo nello standard. L'oggetto Authentication viene passato in ingresso e, se tutto va a buon fine, ne viene rilasciato un'altro in uscita. Nel mio caso ho usato un UsernamePasswordAuthenticationToken, che è già a corredo del framework.
Per dare i ruoli all'utente ho usato una classe AndreaGrantedAuthority che implementa l'interfaccia GrantedAuthority.
Questa classe deve essere poi dichiarata come
security:authentication-provider ref="myAuthenticationProvider"
il tag ref indica che ci dovrà essere un bean spring fatto + o meno così

bean id="myAuthenticationProvider" class="it.andrea.AndreaAuthenticationProvider"

E' ovvio quindi che questo bean è perfettamente integrato in Spring: é quindi possibile iniettare SessionFactory e quant'altro ci possa servire per il reperimento dei dati dell'utente: io per brevità non lo ho fatto ma posso assicurare che funziona.

Da dire che così il gioco non può funzionare, perchè il nostro provider vuole anche uno UserDetailService al quale chiedere com'è fatto l'utente. Infatti il provider si è solo chiesto se l'utente era abilitato o no, non quale fosse in dettaglio il suo profilo.

Per lo UserDetailService mi riprometto di scrivere un nuovo articolo.

Spring Security: primi approcci

Recentemente ho avuto il piacere, chiamiamolo così, di imbattermi in Spring Security.
Spring Securiry è la soluzione di Spring per "mettere in sicurezza" una web application.
La prima cosa da fare è aggiungere un filtro nel web.xml,
usando la classe org.springframework.web.filter.DelegatingFilterProxy
ed intercettando con quella tutte le chiamate, come ben spiegato qui.
La classe sopra citata è il wrapper che intercetta tutte le chiamate.
Per configurarlo è sufficiente editare l'ApplicationContext file: in questo modo ci si riallaccia al meccanismo di gestione di Spring per le web Application.
Scorrendo la documentazione sopra citata si vede che una minima configurazione prevede il tag http. Ora, secondo le specifiche dei files di configurazione di Spring, questo non è possibile. La spiegazione è che, semplicemente, si è usato come default namespace il tag security invece che il tag beans
Se si vuole continuare ad usare il tag beans come default, la dicitura http è da intendersi come security:http
All'interno del tag http è sufficiente specificare authentication-manager ed authentication-provider da usare. Questi due definiscono le regole con cui un utente viene riconosciuto dal sistema.
Authentication-manager contiene la lista dei provider che gestiscono il meccanismo di autenticazione. In pratica si può creare una catena di autenticazioni, ad esempio da database, via LDAP, in memoria, dove ogni authentication-provider implementa la propria logica per dire se è possibile autenticare un utente all'interno del sistema.
Ogni authentication-provider ha uno user-service, cioè un meccanismo che definisce qual'è il profilo dell'utente all'interno dell'applicazione.
Diciamo che i primi approcci su spring-security si fermano qua: interessante sarà analizzare quali sono gli authentication-provider e gli user-service già inclusi nel pacchetto e come fare a crearsi i propri.

Traduzione in inglese qui

Spring 3 e i Web Services

Leggendo la documentazione di Spring 3 si dichiara che Spring supporta 2+1 modi di esporre i Web Services:

• via JAX-RPC
• via JAX-WS
• via Spring Web Services

Ora, io escludo Spring Web Services perchè ha un approccio "Contract-First" alla creazione del webService: cioè prima si crea il wsdl e poi lo si implementa con le classi. Questo è un metodo splendido perchè molto flessibile, ma anche un po' lento nell'implementazione.
Rimangono quindi le altre due strade e fra le due scelgo volentieri quella JAX-WS, una specifica più recente di JAX-RPC, che permette di esporre come Web Services dei semplici POJO.

Per esporli al mondo esterno basta creare una Web Application ed esporre come servlet il POJO.

Vediamo quindi come è la classe che rappresente il Web Service.

@WebService(serviceName="TestService")
public class TestServiceEndpoint {
   
    @WebMethod
    public String sayHello() {
        return "Hello";
    }
}

Questa classe è un banalissimo POJO con 2 annotation una che dichiara che è un webservice, dal nome "TestService" e l'altra che dice che il metodo sayHello è un WebMethod. Ovviamente queste 2 annotations hanno molti altri parametri che permettono una configurazione minuziosa di tutto il Webservice, ma per l'esempio a noi va bene così.

Esponiamo ora il WebService al mondo. Basta creare una WebApplication e nel web.xml, dichiarare il POJO come servlet.

Questo basta per avere un bel WebService. Deploiando ad esempio su JBoss (purtroppo ci vuole un container j2EE per deploiare, ma ormai sono all'ordine del giorno) il gioco è fatto.

Bene, e fin qui abbiamo usato solo J2EE, neanche una traccia di Spring.
Come possiamo fare ad integrare Spring con JAX-WS?

Basta far si che il nostro POJO (o la nostra servlet, se così vogliamo pensarla) estenda SpringBeanAutowiringSupport. Facendo così si può accedere ai bean gestiti da Spring. L'unica limitazione è che queste due "parti" (il POJO e lo Spring context) devono girare nella stessa webApplication.

La classe diventa quindi


@WebService(serviceName="TestService")
public class TestServiceEndpoint extends SpringBeanAutowiringSupport {

   @Autowired
   private HelloService biz;

    @WebMethod
    public String sayHello() {
        return biz.sayHello();
    }
}



L'interfaccia HelloService viene, grazie all'annotation @Autowired, gestita da Spring: questo è il punto di unione tra le due tecnologie.


Per far funzionare il tutto dobbiamo fare una modifica anche al web.xml, aggiungendo la gestione dello SpringContext.


Quindi in fondo al web.xml si aggiunge

Per la parte Spring, basta creare l'xml ApplicationContext.xml (anche qui, si usano i default per velocità)

Qui si dice appunto che la classe che implementa helloService (notare la consonanza di nome tra l'interfaccia e l'id del bean, è uno dei modi in cui Spring ricerca i bean per il metodo @Autowired) è it.ws.test.HelloServiceImpl, che ovviamente implementerà l'interfaccia HelloService.


Tutto qua, nulla di più. Facile vero?