JavaDay in Turin

Next Saturday I'll speak at the JavaDay in Turin.

My presentation will show that the following code can be a fully functional Data Access Object (DAO):
<br />@Dao(entity=Person.class)<br />public interface PersonDao extends GenericDao<Person, Long> {<br /> List<Person> findByLastName(String lastName);<br /> List<Person> findByFirstNameAndLastName(String firstName, String lastName);<br /> List<Person> findByBirthDate(Date birthDate);<br />}<br />
Note, not any other code or configuration to write, just that interface: NO code...NO bugs...more FUN! :)

See you in Turin...

(If you can't...look at the Parancoe site)

JUG Events

Estate abbastanza produttiva...sole, mare, spiaggia, ombrellone...e sviluppo di JUG Events!

Cos'è JUG Events? E' soprattutto la scusa per sperimentare con Parancoe, quindi principalmente con Hibernate/JPA, Spring, Spring MVC e Maven. Ma anche con JCaptcha, JavaMail, Velocity, Plextile, e chi più ne ha, più ne metta.

A parte la sperimentazione, che comunque ha portato nuove idee e sviluppo per Parancoe, l'applicazione può essere utile, quindi l'ho messa online a disposizione dei JUG che vorranno usarla:

www.jugevents.org

Se invece volete studiarne i sorgenti, li trovate nel repository Subversion di Parancoe.

Aggiornamento: JUG Events ha ora un proprio progetto separato per lo sviluppo su Google Code. jugevents.googlecode.com

Iterare il non iterabile in Java

Vi è mai capitato di avere un contenitore di oggetti, che però non sia implementato come Collection? A me purtroppo sì.

Abbondanti esempi li si trova nella libreria XOM. In tale libreria, ad esempio, il metodo Element.getChildElements() restituisce un oggetto Elements, che non è una Collection, ma ha semplicemente i metodi get(index) e size().

L'unico modo per iterare sugli elementi in esso contenuti è scrivere qualcosa del genere:

for(int i=0; i < elements.size(); i++) {
  Element element = elements.get(i);
}

Dato che non implementa l'interfaccia Iterable, ad esempio, non si può usare il comodo "enhanced for" del JDK 5 per scrivere:

for(Element element: elements) {
  // etc...
}

Per superare tale problema ho scritto la classe Iterabletor, che aggiunge ad una qualunque classe l'interfaccia e le capacità di un Iterable. Si può quindi scrivere:
<br />Iterable<Element> iterable =<br /> new Iterabletor<Element>(elements).getIterable();<br /><br />for (Element element: iterable) {<br /> // etc...<br />}<br />
Potete scaricare tutto il codice dal mio sito, nella mini-libreria Utilities.

Maggiori dettagli in questo post nel sito del JUG Padova.

Exim4 relaying on mail.191.it

I'm NOT a sysman...but sometimes it happens.

This post is mainly for my reminder, but I hope it could be useful to other people.

The problem: I have an internal SMTP server (Exim4 on Debian) that must relay to an external smarthost (mail.191.it).

Configure Exim4 as usual, for example typing:

# dpkg-reconfigure exim4-config

For delivering mails to mail.191.it, your SMTP server have to act as SMTP AUTH client.

You have to create /etc/exim4/passwd.client file, and put inside it your connection infos in the following format:

target.mail.server:login:password

Simple, isn'it? But not sufficient...

mail.191.it (and, I think, many other smarthosts) doesn't support TLS encryption, so you have to enable AUTH PLAIN.

Create (if you don't have yet) a /etc/exim4/conf.d/main/000_localmacros file, and write in it:

AUTH_CLIENT_ALLOW_NOTLS_PASSWORDS=yes

Update the configuration:

# update-exim4.conf

...and restart Exim4:

# /etc/init.d/exim4 restart

Of course I'm using the splitted configuration schema. If you are using the non-splitted one, you need to modify the /etc/exim4/update-exim4.conf.conf or /etc/exim4/exim4.conf.template files.

...remember...I'm NOT a sysman...

Spring Meeting 2007

Periodo intenso di conferenze. L'ultima a cui ho partecipato è stata a Cagliari, Spring Framework Meeting 2007, organizzata dallo Spring Framework Italian User Group in collaborazione con il JUG Sardegna.

In quest'occasione ho presentato un seminario dal titolo "Parancoe: usare i DAO senza implementarli", in cui ho mostrato come con Parancoe, che usa pesantemente lo Springframework, assieme ad Hibernate, si possa realizzare in pochissimo tempo e con pochissimo sforzo il layer di persistenza di una propria applicazione.

Qui le trasparenze della mia presentazione: http://snipurl.com/sm2007

Al meeting, in veste di speaker, erano presenti altri due membri del JUG Padova: Paolo Donà ed Enrico Giurin. Il primo ha svolto una presentazione su due caratteristiche recenti di Parancoe che ha sviluppato, ispirandosi a Ruby e RoR: fixtures, per il caricamento di dati nel DB durante i test e in installazione, e plugin, per aggiungere semplicemente funzionalità alle applicazioni sviluppate con Parancoe. Enrico invece ha descritto le funzionalità di ACEGI e il modo in cui tale libreria viene usata nel Plugin Security di Parancoe.

Il meeting, forse anche a causa del bel tempo che ha invogliato molti ad andare al mare, a sofferto di alcuni problemi organizzativi. Alcuni suggerimenti per gli organizzatori, per il prossimo anno:

• pensare ad una giornata meno vacanziera
• indicare meglio la sede, in modo che riesca a trovarla anche chi non è del posto
• distribuire ai partecipanti un volantino con il programma (orario) della giornata, e magari le descrizioni dei vari seminari
• ridurre i tempi di pausa
  
• se i partecipanti previsti non sono molti, com'è stato, usare un'unica sala
• pensare ad un "cane da guardia" per i relatori, in modo che inizino puntuali e non sforino (io, ad esempio, credo di avere abbondantemente sforato...ma in realtà non lo so, dato che non c'era nessuno che controllava il tempo, nemmeno io)

Ad ogni modo, un meeting in Sardegna vale la pena anche solo per la bellezza del luogo.
Purtroppo le mie foto sono pochissime e scattate con un telefonino. Decisamente meglio quelle di Paolo, oppure le foto di Massimiliano Dessì.

Spero che l'anno prossimo venga organizzato ancora, facendo tesoro dell'esperienza di quest'anno...e di riuscire di nuovo a parteciparvi. In bocca al lupo, e W la Sardegna!

PS: devo anche ringraziare Paolo che ci ha ospitato a casa sua, e la sua fantastica nonnina per i buonissimi carciofini sottolio. Un grazie anche a Massimiliano per il suo entusiasmo e per la volontà nell'organizzare questo evento.

Jazoon '07

La settimana scorsa ho partecipato a Jazoon '07, prima edizione di una conferenza dedicata alle tecnologie Java che si svolge a Zurigo.

Durante la conferenza, assieme ad altri due membri del JUG Padova, abbiamo presentato una demo su Parancoe, un meta-framework Web opensource con alcune caratteristiche innovative per accelerare lo sviluppo di applicazioni Web.

La conferenza è stata piuttosto interessante. Potete leggerne il mio resoconto nel sito del JUG.

Tomcat "castrato"

...ovvero come perdere una giornata di lavoro credendo che fosse colpa di LifeRay e invece era colpa di Tomcat. (ma anche LifeRay ci ha messo del suo)

Partiamo dalla soluzione, che è un po' più utile. Se usando Tomcat (5.5.20...ma anche 5.5.17, non ho provato gli altri) vi succede di non riuscire a usare le mail session configurate come risorse JNDI dato che facendone il lookup ricevete in risposta una bella ClassNotFoundException: org.apache.naming.factory.MailSessionFactory, la colpa non è vostra, ma di quei burloni che sviluppano Tomcat che si sono dimenticati di distribuirla. Tale classe dovrebbe trovarsi in common/lib/naming-factory.jar, ma viene inclusa solo se durante il build di Tomcat si è avuta l'accortezza di mettere nel classpath le JavaMail e il JavaBeans Activation Framework. Non so se questo sia voluto, visto che ormai si ripete da almeno 2 versioni, certo è che è una bella scocciatura.

Ho quindi dovuto ricompilare Tomcat dai sorgenti (5.5.20) per produrre un JAR contenente le factory mancanti. Dato che non è proprio semplicissimo, se volete evitarvi la fatica potete scaricarlo da qui:

http://snipurl.com/nfjar

Sostituitelo a quello presente in common/lib.

Il punto di partenza del problema è stato ancora più subdolo...da qui la giornata persa. Infatti stavo cercandi di far funzionare le mail session con LifeRay, usando ovviamente Tomcat come Servlet/JSP container. Il problema segnalato da LifeRay non era la tutto sommato chiara ClassNotFoundException, bensì una incomprensibile javax.naming.NameNotFoundException: Name mail is not bound in this Context. Ovviamente, controllando la console di amministrazione, il nome JNDI era definito! Il problema è che LifeRay cerca di "indovinare" il nome JNDI (che ovviamente cambia da server a server), ma facendo questo si perde (ignorandole e nascondendocele completamente) le vere cause dei problemi...quindi un'intera giornata persa cercando di configurare le risorse JNDI, quando invece bisognava "aggiustare" un JAR.

Per fortuna comunque che LifeRay è opensource e ho potuto esaminarne i sorgenti per capire la vera causa di questo errore, altrimenti sarebbe stato impossibile.