Development Blog

Discovering.... Server Push! #2

2014-01-06T11:00:00.000+01:00

Seconda puntata dedicata ai concetti di push e Comet nello sviluppo web. Nella scorsa puntata abbiamo parlato di long polling e HTTP streaming. Continuiamo l'excursus, parlandovi di Server-Sent events e web sockets.

Fonte: www.stream-hub.com

Server-Sent Events

Questa è una delle due tecniche di push effettivo rese disponibili dall’HTML 5. Il client, tramite la nuova interfaccia javascript EventSource, apre una connessione verso un url e rimane in ascolto di eventi generati dal server:

var eventSource = new EventSource("www.mioserver.com/miapagina");

A questo punto il client può rimanere in ascolto di eventi nel seguente modo:

eventSource.onMessage = function(e) { /* codice... */ };

O nel seguente modo, registrando un listener per uno specifico evento:

eventSource.addEventListener(
“nome_evento”, function(e) { /* codice… */ }, false);

Questa tecnica, a differenza dei web socket, crea un canale di comunicazione dal server al client, quindi unidirezionale. Un vantaggio però è che i SSEs utilizzano il protocollo HTTP tradizionale, quindi non richiedono delle particolari configurazioni sul server per funzionare.

Web Sockets

Veniamo infine alla tecnica più potente, i web socket. L’utilizzo lato client è molto simile ai SSEs (l’interfaccia qui si chiama WebSocket), con due differenze però.

La prima è che la comunicazione stabilita tra client e server è bidirezionale. E’ quindi possibile mandare dei messaggi dal client al server, nel seguente modo:

webSocket.send(“Hi server!”);

Per quanto riguarda la comunicazione dal server al client, invece, non ci sono grosse differenze con i SSEs, se non per il fatto che con i web socket non è possibile diversificare i tipi di messaggio (niente addEventListener quindi).

Questa tecnica non utilizza il protocollo HTTP, ma un suo protocollo specifico. Questo significa che il server (oltre che il browser) deve essere predisposto per supportarlo.

Conclusioni

Le tecniche, come mostrato, sono molte, e la loro disponibilità dipende sia dall’application server utilizzato che dal browser. Conviene decisamente astrarre. Sia lato client che lato server esistono librerie e framework per alleggerire il lavoro: citando le prime due cose che mi vengono in mente, jQuery ha varie utilities per comunicare in JSONP e SpringMVC rende snello operare con le servlet asincrone.

Ma il livello massimo di astrazione lo si ha utilizzando Atmosphere. Lo scopo di questo framework è lasciare che sia lui a scoprire la tecnica più adatta per l’environment corrente (AS e browser). Atmosphere è già integrato in molti framework: esiste, ad esempio, il modulo per Spring.

Vi lascio con un utile link, preso dal wiki di Atmosphere, che mostra cosa supportano attualmente server e browser. Alla prossima!

Marco Zarantonello
m.zarantonello@miriade.it

Liferay: integrazione con Apache Solr. II puntatata

2013-12-30T11:00:00.000+01:00

Riprendiamo la seria dedicata a Liferay, e in particolare all'integrazione tra il portale e Apache Solr. Nella scorsa puntata, abbiamo visto le basi, come l'installazione di Solr e avevamo visto come sistemare la compatibilità con le librerie httpclient e httpcore..e da qui riprendiamo.

Abbiamo quindi implementato una versione custom di HttpClient che nativamente supportasse la basicauth preemptive:

@ThreadSafe

public class PreemptiveHttpClient extends DefaultHttpClient {

private Credentials credentials = null;

protected BasicHttpProcessor createHttpProcessor() {
BasicHttpProcessor processor = super.createHttpProcessor();
processor.addInterceptor(new RemoveHttpHeadersInterceptor(), 0);
processor.addInterceptor(new PreemptiveAuthInterceptor(), 1);
return processor;
}

public PreemptiveHttpClient(){
super();
}

public PreemptiveHttpClient(org.apache.http.conn.ClientConnectionManager connManager){
super(connManager);
}

public void setCredentials(Credentials cred){
setCredentials(AuthScope.ANY, cred);
}

public void setCredentials(AuthScope scope, Credentials cred){
getCredentialsProvider().setCredentials(scope, cred);
credentials = cred;
}

private class PreemptiveAuthInterceptor implements HttpRequestInterceptor {
   @SuppressWarnings("deprecation")
public void process(final HttpRequest request, final HttpContext context) throws HttpException, IOException {
       AuthState authState = (AuthState) context.getAttribute(ClientContext.TARGET_AUTH_STATE);

       // If no auth scheme avaialble yet, try to initialize it preemptively
       if (authState.getAuthScheme() == null) {
           CredentialsProvider credsProvider = (CredentialsProvider) context.getAttribute(ClientContext.CREDS_PROVIDER);
           HttpHost targetHost = (HttpHost) context.getAttribute(ExecutionContext.HTTP_TARGET_HOST);
           Credentials creds = credsProvider.getCredentials(new AuthScope(targetHost.getHostName(), targetHost.getPort()));
           if (creds == null && PreemptiveHttpClient.this.credentials == null)
               throw new HttpException("No credentials for preemptive authentication");
           authState.setAuthScheme(new BasicScheme());
           authState.setCredentials(creds != null ? creds : credentials);
       }
   }
}

private static class RemoveHttpHeadersInterceptor implements HttpRequestInterceptor {
public void process(HttpRequest request, HttpContext context) throws HttpException, IOException {
if (request instanceof HttpEntityEnclosingRequest) {
if (request.containsHeader(HTTP.TRANSFER_ENCODING)) {
request.removeHeaders(HTTP.TRANSFER_ENCODING);
}
if (request.containsHeader(HTTP.CONTENT_LEN)) {
request.removeHeaders(HTTP.CONTENT_LEN);
}
}
}
}
}
Una volta fatto ciò basterà istanziare la nuova classe all’interno del BasicAuthSolrServer, ed il gioco è fatto!
Gli ultimi due step, ampiamente documentati nelle guide online, sono di inserire l’indirizzo dell’applicazione web solr installata all’interno del file META-INF/solr-spring.xml:
<bean id="com.liferay.portal.search.solr.server.BasicAuthSolrServer" class="com.liferay.portal.search.solr.server.BasicAuthSolrServer">
<constructor-arg type="java.lang.String" value="http://YOURSOLRSERVER:PORT/solr" />
</bean>
e di copiare il file /WEB-INF/conf/schema.xml all’interno della nostra installazione di solr.
Impacchettate il vostro war, deployate il plugin aggiornato e godetevi il vostro nuovo sistema di indicizzazione!

Emanuele Righetto

Discovering.....Server Push! #1

2013-12-16T16:26:00.003+01:00

Nello sviluppo web si sente spesso parlare di push e di Comet. Andiamo nel dettaglio a capire di cosa si tratta.

www.stream-hub.com

Il server push è un tipo di comunicazione web per cui una richiesta ha origine dal server ed è diretta al client. Stiamo parlando di web, quindi con server intendiamo l’application server che ospita un’applicazione e come client intendiamo il browser con il quale si fruisce l’applicazione stessa.

Per spiegare brevemente il push basti pensare al comportamento di un client web di posta evoluto, come gmail. Non appena viene ricevuta una mail essa appare subito nell’inbox, senza ricaricare la pagina. E’ evidente che la richiesta HTTP non è (almeno formalmente) partita dal mio browser, ma è il server che mi sta notificando in tempo reale.

Come si ottiene tutto ciò? In questo e nel mio prossimo post andremo ad analizzare le varie tecniche con le quali il push può essere implementato. Scopriremo che molte sono solo dei workaround che ne emulano l’effetto, identificate usualmente con il termine “Comet”. Con i Server-Sent Events e i Websocket, entrambi di recente introduzione, si ha invece il push vero e proprio.

Long-polling

Prima di parlare di long-polling, capiamo come funziona il polling standard. Una volta caricata una pagina web partono dal browser, ad intervalli regolari, delle richieste AJAX che reperiscono dal server, se presenti, delle informazioni. Un esempio per un client di posta può essere ogni 30 secondi chiedere al server se è arrivata una nuova mail. In caso affermativo tale mail viene mostrata in cima all’inbox.

L’inefficienza di questa tecnica sta proprio negli intervalli di chiamata. Ottenere un “effetto push” con il polling standard significherebbe fare, ad esempio, una richiesta al secondo, cosa ovviamente da evitare.

Il long-polling non soffre di questo problema perchè non funziona ad intervalli regolari. Con questa tecnica il server risponde al client solamente quando ha effettivamente qualcosa da ritornare (es. è arrivata una nuova mail), o scade un timeout prefissato. Non appena una chiamata ritorna al client, ne parte subito un’altra.

Long-polling with JSONP

A causa della “same-origin policy”, una pagina web fornita da uno specifico server non può comunicare con un server diverso dallo stesso, per ragioni di sicurezza. Esiste però uno stratagemma per ovviare a questo: i tag <script> inseriti in una pagina possono caricare del javascript proveniente da un altro server. La tecnica del JSONP sfrutta questo per leggere dati (potenzialmente in long polling) da un server qualsiasi.

Supponiamo che l’url a cui la pagina fa una richiesta tramite tag <script> ritorni dati in formato JSON. Tali dati non rappresentano un javascript corretto; per diventarlo dovrebbero essere assegnati a una variabile oppure passati come parametro a una chiamata di funzione. E qui entra in gioco JSONP, ossia “JSON with Padding”: aggiungendo all’url chiamato il parametro callback è possibile specificare il nome di una funzione javascript locale che verrà chiamata con l’oggetto JSON passato come argomento. Il payload della chiamata a questo punto diventa codice javascript formalmente corretto che verrà eseguito quando la risposta viene ricevuta dal server (che potrebbe operare in long-polling).

Mi ri-spiego con del codice. Supponiamo che l’indirizzo www.mioserver.com/miapagina risponda in formato JSON. Inserendo in una pagina web lo script

<script type=”application/javascript”
src=”www.mioserver.com/miapagina?callback=handleResponse” />

, tale script ritornerebbe ed eseguirebbe il seguente javascript:

handleResponse(<oggetto JSON ritornato>);

La funzione handleResponse è una funzione javascript locale, la quale effettuerà qualche operazione con i dati ritornati e, supponendo si operi in long-polling, aggiungerà un nuovo tag <script> al DOM della pagina (e così via…).

HTTP Streaming

L’HTTP Streaming è il passo successivo al long-polling. In sostanza il client apre una e una sola connessione verso il server. Questo la mantiene sempre aperta, ritornando al client delle risposte parziali quando i dati sono disponibili (utilizzando il cosiddetto “chunked transfer encoding”).

La tecnica può essere utilizzata sia con le chiamate AJAX XHR, sia tramite lo stratagemma del “forever frame”. In sostanza la pagina ospita un <iframe> nascosto, il quale carica il suo contenuto (dei tag <script> ad esempio) in modalità chunked.

Implementare risposte parziali lato server è ora semplice con le Servlet API 3.0. E’ stato introdotto infatti il concetto di servlet asincrona, che, delegando il lavoro ad un altro thread, può aggiungere dati alla risposta di tanto in tanto e chiudere la richiesta in un secondo momento.

Siamo molto vicini al concetto di push vero e proprio, attenzione però al carico di memoria nel browser (la chiamata HTTP è una sola e le risposte parziali vanno ad accumularsi).

Aggiungo anche che il server deve essere predisposto a supportare delle connessioni long-running. Nel caso di Tomcat si può abilitare il connettore NIO, che utilizza un threading model ottimizzato: con questo connettore si evita che rimangano thread occupati a lungo per servire una sola richiesta.

E questo è tutto per quanto riguarda le tecniche Comet. Sintonizzatevi sulla prossima puntata dove vedremo le succose novità per il push rese disponibili dall’HTML 5.

Marco Zarantonello
m.zarantonello@miriade.it

Continuous Integration - part 1

2013-12-02T11:00:00.000+01:00

A quick tutorial to put down an entire CI system for a JavaEE web application. Stay tuned!

PART 1

Hi all, here you find a very quick and easy guide to put down an entire CI system for a JavaEE web application using a lot of useful software in the shortest time possible. To achieve this not trivial target, I’ll need to skip a complete description of all steps. If something is not explained deeply enough it means: just google it and you’ll find what you need.

First we start immediatly with the backbone of the building system: Gradle.

Gradle is an amazing building tool and because this guide want to be really quick I will not explain here what this wonderful tool is, you could find all documentation you need at http://www.gradle.org/documentation.

As best practices says: “use the wrapper” and so we do. Create a file build.gradle in the project home and the add this lines

task wrapper(type: Wrapper) {

gradleVersion = '1.9'

}

then call

user@domain:~$ gradle wrapper

this will install gradle locally so you do not need to setup your system.

One you have done this, we could add some lines that adds some useful plugins.

apply plugin: 'java'

apply plugin: 'maven'

apply plugin: 'war'

apply plugin: 'jacoco'

apply plugin: 'idea'

apply plugin: 'eclipse-wtp'

apply plugin: 'findbugs'

all of this plugins help offering useful tasks that we will use to compile the code, check dependencies and a lot of interesting stuff that would be very boring if we must do them manually. Obviously ‘idea’ and ‘eclipse-wtp’ plugins are needed only if you use theese IDE, remove them otherwise.

If you have a multi-module project would be better if you check some best practices contained on gradle user guide and checking for a real life example the build.gradle file of the springframework project on git-hub.

Now we’ll add our project dependencies. Theese could be local jars, entire projects or artifacts. Let’s assume that we only need a maven repository to download our jars.

In the gradle user guide you’ll find a way to add dependencies to other projects, with Ivy or custom maven repository, or just local jars.

dependencies {

compile 'javax.servlet:servlet-api:2.5'

compile 'com.amazonaws:aws-java-sdk:latest.integration'

compile 'org.hibernate:hibernate-core:4.2.5.Final'

compile 'org.springframework:spring-context:3.2.5.RELEASE'

compile 'org.springframework:spring-context-support:3.2.5.RELEASE'

compile 'org.springframework:spring-test:3.2.5.RELEASE'

compile 'org.springframework.security:spring-security-web:3.1.4.RELEASE'

compile 'org.springframework.security:spring-security-config:3.1.4.RELEASE'

compile 'org.springframework.hateoas:spring-hateoas:0.7.0.RELEASE'

compile 'org.quartz-scheduler:quartz:2.2.1'

compile 'org.apache.commons:commons-lang3:latest.integration'

compile 'log4j:log4j:latest.integration'

compile 'org.codehaus.jackson:jackson-mapper-asl:latest.integration'

testCompile 'junit:junit:4.+'

testCompile 'org.hamcrest:hamcrest-all:latest.integration'

testCompile 'org.mockito:mockito-all:latest.integration'

testCompile 'com.jayway.jsonpath:json-path:latest.integration'

}

Then we define a new sourceSet for integration tests, in this way the java plugin will compile it.

sourceSets {

integrationTest {

java.srcDir file('src/integTest/java')

resources.srcDir file('src/integTest/resources')

compile.ext['classpath'] = sourceSets.main.output + configurations.testRuntime

runtimeClasspath = output + compileClasspath

}

So we define a new task that add our integration tests to the test step of the build.

task integrationTest(type: Test) {

description = 'Run all the integration tests'

group = 'verification'

testClassesDir = sourceSets.integrationTest.output.classesDir

classpath = sourceSets.integrationTest.runtimeClasspath

reports.junitXml.destination = file("$reports.junitXml.destination/integration")

}

After this beacuse we want to add Jacoco and Findbugs report that we will use with Jenkins we need to add a little bit of further configurations

findbugs {

toolVersion = "2.0.1"

sourceSets = [sourceSets.main]

ignoreFailures = true

reportsDir = file("${buildDir}/reports/findbugs")

effort = "max"

reportLevel = "high"

}

jacocoTestReport {

reports {

xml.enabled false

csv.enabled false

html.destination "${buildDir}/reports/jacoco"

}

// adding integrationTest and Jacoco report to the check step

check {

dependsOn integrationTest

dependsOn jacocoTestReport

}

At this point we need to define a custom versioning policy for the artifacts that we want to build. So just create a new file called versioning.gradle under $PROJECT_HOME/gradle and fill it with this

ext.buildTimestamp = new Date().format('yyyy-MM-dd HH:mm:ss')

version = new ProjectVersion("${version_major}" as Integer, "${version_minor}" as
Integer, System.env.BUILD_NUMBER)

class ProjectVersion {

Integer major

Integer minor

String build

ProjectVersion(Integer major, Integer minor, String build) {

this.build = build

this.major = major

this.minor = minor

}

@Override

public java.lang.String toString() {

String fullVersion = "$major.$minor"

if(build) {

fullVersion += ".$build"

}

return fullVersion

}

We now add a bunch of lines that will create the buildInfo file, used for artifact informations

task createBuildInfoFile << {

def buildInfoFile = new File("$buildDir/build-info.properties")

Properties props = new Properties();

props.setProperty('version', project.version.toString())

props.setProperty('timestamp', project.buildTimestamp)

props.store(buildInfoFile.newWriter(), null)

}

Now we configure the war plugin that we need to create our artifact.

war {

dependsOn createBuildInfoFile

baseName = project.name

webInf { from 'WebContent/WEB-INF' }

from(buildDir) {

include 'build-info.properties'

into('WEB-INF/classes')

}

This is all you need to setup Gradle for building. You could find the complete build.gradlefile here. In the coming posts we’ll setup Jenkins and Artifactory to complete the puzzle. See ya =)

Liferay: integrazione con Apache Solr. I puntata

2013-11-18T11:00:00.000+01:00

Questa settimana riprendiamo un topic che di cui avevamo già parlato tempo fa, ma che per diversi mesi avevamo lasciato in sospeso: Liferay. In due post, vi racconteremo l'integrazione tra il portale e Apache Solr, ovviamente partendo da un caso aziendale. Buona lettura!

Per chi non lo conoscesse Solr è un’enterprise open-source search platform, sviluppato da Apache e basato sulle librerie Lucene, largamento utilizzate proprio per l’indicizzazione e la ricerca di contenuti.

L’applicativo, sviluppato in Java, richiede solamente l’utilizzo di un servlet container (come jetty o tomcat) per funzionare.

E qui, ad essere sinceri, c’è una piccola grande delusione.
Abbastanza semplice, ma questo trucco non funziona con la versione di Solr appena installata. Il motivo? Dalla versione 4 Solr utilizza al suo interno le librerie httpclient e httpcore aggiornate a loro volta alla versione 4.x, che introducono diverse novità, ma purtroppo non sono retrocompatibili.

Questa possibilità ci è preclusa con le nuove librerie.

Ma andiamo per ordine..

Ad agosto Liferay ha rilasciato la versione 6.1.3 (6.1 GA3) del suo portale, introducendo come sempre molte novità. Una queste, come preannunciato già dalla versione 6.1, è stata la rimozione del supporto a Lucene come motore di indizzazione per le configurazioni cluster.

Niente di nuovo, l’utilizzo di questa libreria era già deprecato da tempo e le guide ufficiali consigliavano fortemente il passaggio ad un nuovo strumento di indicizzazione.

L’aggiornamento a questa release, presso uno dei clienti più importanti, ci ha dato l’opportunità di implementare l’integrazione tra i due strumenti.
I primi passi sono stati molto semplici: rimuovere la configurazione lucene dai settings di Liferay ed installare Solr in un server linux (centos) dedicato.
Abbiamo scelto di scaricare ed installare l’ultima release disponibile, la 4.4, che dispone anche di un installare automatico. In pochissimi minuti solr sarà attivo e funzionante, e la nuova versione dispone anche di una pratica e funzionale interfaccia web che permette di verificare lo stato del sistema e di eseguire query sui contenuti già indicizzati.
Lo step successivo è quello di scaricare, direttamente dal pannello di controllo di Liferay (“Marketplace”), il plugin per la connessione appunto a Solr.
Il plugin è “ufficialmente” compatibile con la versione 1.4 di Solr (avete letto bene, 1.4!).
Ufficiosamente invece molti post, alcuni su forum ufficiali, suggeriscono che in realtà il plugin funziona correttamente anche con le versioni 3.x di Solr, con la piccola accortezza di sostituire due jar (solr-core.jar e solr-solr.jar) all’interno del plugin.
Conflitto di librerie quindi, un problema che fa veramente inc***are ogni programmatore.
La soluzione inevitabile è stata quella di aprire i codici sorgente (fortunatamente presenti nel war del plugin) e fixare a mano questi problemi.
Una volta sostituite le librerie all’interno del progetto diverse classi presenteranno errori di compilazione.
Per la maggior parte di esse il problema è dovuto all’utilizzo della classe MultiThreadedHttpConnectionManager, non più supportata e del tutto rimossa dalla libreria.
Al suo posto sarà necessario utilizzare la nuova più performante PoolingClientConnectionManager.
Il problema principale è rappresentato dalla classe BasicAuthSolrServer, che utilizza il vecchio HttpClient che supportava facilmente l’autenticazione basic auth preemptive, come evidenziato nelle righe dalla 60 alla 70:
HttpState httpState = httpClient.getState();
httpState.setCredentials(authScope,
new UsernamePasswordCredentials(_username, _password));
HttpClientParams httpClientParams = httpClient.getParams();
httpClientParams.setAuthenticationPreemptive(true);

Purtroppo, questa possibilità ci è preclusa con le nuove librerie. Nel prossimo post, impareremo come supportare la basicauth preemptive. Ci vediamo il 26 Dicembre!

Emanuele Righetto

Primefaces 4.0: finalmente disponibile l'ultimo nato in casa Prime Technology

2013-10-21T09:00:00.000+02:00

Dal 3 ottobre è possibile scaricare la release ufficiale di Primefaces 4.0: l’abbiamo provata per voi.

Dopo i miei due post di introduzione al framework (qui e qui), ritorno sul tema per andare ad analizzare le novità dell’ultima release stabile, uscita a inizio mese.

SUPPORTO JSF 2.2

La libreria è ora JSF 2.2 compliant. Sono quindi ora supportate features come:

pass through attributes: attributi che vengono renderizzati tali e quali a come vengono scritti, senza essere processati;
reset values: un attributo che va a risolvere il noto problema dei componenti di una form che rimangono “corrotti” dopo un errore di validazione;
API per il file upload come da specifica Servlet 3.x; il componente Primefaces per il file upload è stato riscritto da zero.

CLIENT SIDE VALIDATION

Qui le cose si fanno interessanti. Semplicemente aggiungendo validateClient="true" al command button o al tag ajax si sposta tutto il processo di validazione dei campi della form dal server al client (!!!). Questo viene out-of-the-box per le validazioni semplici (come il required, il minimo/massimo di un numero, le regex, ecc.), mentre per validazioni più complesse occorre scrivere del javascript per implementarle.

DIALOG FRAMEWORK

Con il nuovissimo dialog framework è possibile, dal RequestContext java, dire al client di aprire una specifica facelet all’interno di una dialog (eventualmente modale, ridimensionabile e/o trascinabile). Tale facelet può poi comunicare con lo scope principale ritornando dei valori, sempre tramite il RequestContext. Per leggere tali valori è disponibile il nuovo evento ajax “dialogReturn”. Questo framework permette quindi di rendere il codice più modulare, disaccoppiando effettivamente la logica sia lato facelet che lato backing bean.

SEARCH EXPRESSIONS

Di questo vi avevo già accennato qualcosa nelle precedenti puntate. In sostanza Primefaces incrementa ulteriormente il set di keyword utilizzabili negli attributi process e update per andare a referenziare i componenti della pagina. Sono disponibili i nuovi @composite, @namingcontainer (il composite component / naming container circostante), oltre che @child(n) (l’ennesimo figlio del componente corrente) e @widgetVar(...) (risoluzione del componente tramite la variabile javascript associata). E la cosa veramente utile è che queste keyword si possono concatenare, creando espressioni come @this:@parent:@child(1).

DEFERRED LOADING

Il componente outputPanel, finora utilizzato principalmente per la possibilità di auto-update, è ora dotato di deferred loading. Questo significa che dei frammenti della pagina possono essere richiesti al server e renderizzati in un secondo momento: dopo il caricamento della pagina stessa oppure quando, tramite scroll, si arriva al punto in cui devono essere visualizzati.

NUOVI COMPONENTI E IMPROVEMENTS SU ESISTENTI

Vari nuovi componenti sono stati aggiunti. Ve ne cito due che ho trovato molto utili: la confirm dialog generica, soluzione molto elegante che va ad alleggerire di molto il codice (o almeno il mio codice, che era pieno di dialog di conferma custom -_-), e lo sticky: semplicemente agganciando il tag p:sticky a un componente lo si rende sempre visibile nella pagina, anche dopo lo scroll (utilissimo per le toolbar). Oltre a nuovi componenti, nuovi attributi sono disponibili per molti componenti già esistenti.

Ovviamente è già disponibile tutta la documentazione relativa alla nuova release (Primefaces in questo, bisogna dirlo, eccelle).

Il framework è scaricabile dalla pagina http://www.primefaces.org/downloads.html.

Vi lascio con un video, rilasciato da Prime Technology per presentare Primefaces 4.0: http://vimeo.com/73010469. Buona visione :)

Marco Zarantonello

m.zarantonello@miriade.it

Bootstrap 3 RC1: come cambia il toolkit di Twitter

2013-10-07T08:30:00.000+02:00

A fine Luglio, in occasione del suo secondo anniversario, Bootstrap rende disponibile il download della release 3.

Come annunciato sul post di lancio, molto è cambiato dalla versione precedente. Il lavoro di nove mesi tra design e sviluppo ha richiesto infatti oltre 2700 commit (da parte di 319 utenti) e la modifica di 379 file, corrispondenti a 84k righe aggiunte o eliminate.

Andiamo a vedere in dettaglio le features introdotte con l'ultima release.

Mobile first. Si è partiti dallo sviluppare il framework prima di tutto per i mobile devices, aggiungendo via via le direttive css compatibili con tablet e desktop. Il risultato è una responsive web experience che si adatta agilemente a schermi di dimensioni variabili. Gli stili per il mobile si trovano sparsi su tutta la libreria, anzichè su un file separato.

Flat Design. Boostrap 3 si è rivolto verso una grafica completamente flat, ma è stato aggiunto anche un optional visual theme simile al design precedente: non dovrebbe così mancare il look and feel di Boostrap 2.x.

Grid System. Le precedenti versioni di Bootstrap erano caratterizzate da una grid system minimale (il già noto paradigma a 12 colonne), ora è invece possibile avere pieno controllo della CSS layout grid. Sostanzialmente è cambiato il modo con cui vengono creati gli spazi che contengono gli elementi della pagina web. La correzione più consistente sta nella dichiarazione delle colonne. Il vecchio .spanX è sostituito dalle classi .col-lg-X per i desktop, .col-sm-X per i tablet e .col-X per i mobile. Il sistema diventa così più versatile, così da poter avere piena padronanza di come sarà visualizzata la pagina nei tre tipi di dispositivi (ancora una volta il workflow di sviluppo è stato adattato al mobile).

Browsers. E' stato rimosso il supporto a Internet Explorer 7 e Firefox 3.6. Su Internet Explorer 8 è necessario inserire il JavaScript Respond.js per far funzionare correttamente le varie media query.

Sul sito del framework è disponibile una sezione per migrare da Bootstrap 2.x a Boostrap 3.

Altra valida traccia si può trovare qui.
Il maintaining e il supporting della versione 2.3.2 non sarà più garantito.

Il punto più importante rimane però l'1% di siti web che utilizzano questo framework: in pochissimo tempo infatti Boostrap è riuscito a guadagnarsi una grossa fetta di mercato proprio per la sua rapida costruzione di interfacce di siti e web applications.

Federica

f.sgarbossa@miriade.it

Spring Security Tips: Custom Security Tags

2013-09-23T09:00:00.000+02:00

Dopo aver visto come creare espressioni personalizzate da usare all’interno di SpringSecurity, aumentiamo ancora il livello di personalizzazione, andando a creare un tag jsp personalizzato che faciliti ulteriormente la gestione della sicurezza nelle nostre pagine web.

Abbiamo già visto come usare espressioni personalizzate all’interno di tag e annotation di Spring Security.
Ma gli sviluppatori, si sa, sono pigri e hanno scarsa memoria, per cui anche solo ricordarsi tutte le nuove espressioni è noioso e faticoso.
La soluzione? Introdurre nuovi tag che semplicemente si ricordino per noi le espressioni che possiamo utilizzare!

La procedura è abbastanza semplice, e possiamo riassumerla in pochi punti:

creare un file tld che definisca il nostro nuovo tag (o i nostri tag, se ne vogliamo più di uno);
informare il nostro application server che esiste una taglib nostra, segnalandone l’esistanza nel file web.xml;
includere la taglib appena creata nei file jsp in cui intendiamo usarla;
scrivere la classe che si occuperà di realizzare effettivamente i check di sicurezza;
iniziare ad utilizzare il nostro nuovo tag nelle pagine.

Ma andiamo per ordine.
Per definire la nostra taglib possiamo ovviamente prendere spunto da quello che già offre Spring Security. Un buon inizio è il file security.tld che si trova all’interno di spring-security-taglibs-3.1.3.RELEASE.jar.
Sarà necessario indicare una classe (che implementeremo al punto 4) e definire una serie di tag <attribute>. Ognuno di questi sarà un attributo del tag che stiamo realizzando e il nostro editor sarà in grado di proporci la serie degli attributi disponibili, così come accade per gli altri tag html o jsp che già utilizziamo.
Nella nostra concezione iniziale di questo tag, ogni attributo equivarrà ad una possibile espressione che dovrà essere valutata per autorizzare l’accesso al contenuto del tag.
In questa ottica, il tag potrà essere utilizzato senza attributi (nessun controllo di accesso) o con una combinazione arbitraria degli attributi disponibli.

Una volta definita la struttura e gli attributi del nostro tag, indicheremo all’application server questa nuova taglib, all’interno del file web.xml:


 <jsp-config>
    <taglib>
         <taglib-uri>http://www.springframework.org/security/actions</taglib-uri>
         <taglib-location>/WEB-INF/actions.tld</taglib-location>
     </taglib>
 </jsp-config>

In alternativa è possibile inserire questo file (assieme possibilmente alle classi necessarie al suo utilizzo) in un jar da includere nel classpath dell’applicazione.
La taglib è ora (quasi) pronta per essere inserita nelle nostre pagine:


 <%@ taglib prefix="actions" uri="http://www.springframework.org/security/actions"%>

Resta da implementare la classe che conterrà la logica del nostro tag, che dovrà necessariamente implementare l’interfaccia javax.servlet.jsp.tagext.Tag.
Un buon punto di partenza per scrivere tale classe potrebbe essere JspAuthorizeTag, che si occupa della gestione del tag <sec:autorize>, sicuramente già noto a chiunque abbia usato SpringSecurity.

Il metodo principale di tale classe dovrà gioco forza essere


 public boolean authorize() throws IOException{...}

che dovrebbe occuparsi di verificare l’uso dei vari attributi per quella particolare istanza del tag e controllare se l’utente abbia o meno i requisiti necessari (dettati appunto dagli attributi) per accedere al contenuto del tag.
Come da tradizione accademica, lasciamo al lettore come esercizio l’implementazione di questa classe, partendo appunto dal codice di JspAuthorizeTag che è facilmente consultabile dal repository Github di Spring.

Un esempio dell’utilizzo di un tag personalizzato realizzato per l’applicazione “Bot” da Miriade:


 <sec:resource hasAnyPage="Reports">
 <li class="nav-header">Reports</li>
     <li><a href="<c:url value="/reports"/>">Generic Reports</a></li>
     <sec:resource hasAnyPageResources="Reports:hr,admin">
        <li><a href="<c:url value="/admin-reports"/>">Admin Reports</a></li>
     </sec:resource>
 </sec:resource>

Come già anticipato all’inizio, l’uso di questi tag è solamente uno “shortcut” per evitare di ricordarsi tutte le nuove espressioni definite nella puntata precedente e può essere benissimo evitato usando il tag:


 <sec:authorize access=”customExpression..() and customExpression2(..)”>...</sec:authorize>.

Flessibilità o comodità? Ai posteri l’ardua sentenza.

Emanuele Righetto
e.righetto@miriade.it