www.jugpadova.it: Category Programmazione

Debugging tests of a Maven project in NetBeans

Lucio Benfante — Wed, 20 Feb 2008 11:30:00 -0600

Occasionally I experienced some problems in debugging test classes using NetBeans with Maven projects. Simply, the debugger started but didn’t attach to the running tests.

Eventually I discovered the reason!

I used to configure the surefire plugin with:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <skip>false</skip>
        <useFile>true</useFile>
        <forkMode>once</forkMode> <!-- always, once or never -->
        <!-- <reportFormat>plain</reportFormat> -->
        <argLine>-Xmx512M</argLine>
    </configuration>
</plugin>

The problem is the argLine parameter. It will override the parameters the Mevenide plugin will pass for debugging tests. So, I commented it in my configuration:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <skip>false</skip>
        <useFile>true</useFile>
        <forkMode>once</forkMode> <!-- always, once or never -->
        <!-- <reportFormat>plain</reportFormat> -->
        <!--argLine>-Xmx512M</argLine--> <!-- don't use if you want to debug tests in NetBeans -->
    </configuration>
</plugin>

...and now I can debug my tests!

JUG Events

Lucio Benfante — Mon, 03 Sep 2007 16:01:28 -0500

JUG Events è finalmente online!

www.jugevents.org

A parte l’utilità dell’applicazione per il nostro e gli altri JUG, mi preme qui sottolineare che è la prima applicazione sviluppata dal JUG Padova, e spero non l’ultima.

Gli sviluppatori di JUG Events siamo stati principalmente io ed Enrico, con il supporto di Paolo F. Ma l’applicazione usa il nostro framework Parancoe, quindi gran parte del merito va anche a tutti quelli che hanno contribuito e partecipano al suo sviluppo.

Tomcat 5.5.20 and JavaMail Sessions

Lucio Benfante — Tue, 13 Mar 2007 07:40:00 -0500

You’ll find an article in italian on the same topic in my personal blog.

In Tomcat you can define a JNDI Resource for a JavaMail session putting the following code in you Context definition:

<Resource name="mail/Session" auth="Container"
            type="javax.mail.Session"
            mail.smtp.host="localhost"/>

And in you web.xml:

<resource-ref>
  <res-ref-name>mail/Session</res-ref-name>
  <res-type>javax.mail.Session</res-type>
  <res-auth>Container</res-auth>
</resource-ref>

Then you can use it in you code:

Context initCtx = new InitialContext();
Session session =
    (Session) envCtx.lookup("java:comp/env/mail/Session");

Using Tomcat 5.5.20 (and 5.5.17, and 5.5.23…and maybe other versions) the last statement will produce a ClassNotFoundException: org.apache.naming.factory.MailSessionFactory. The cause is obviously that class is missing from the common/lib/naming-factory.jar distributed by Tomcat. I don’t know if it was a (repeated) problem in building Tomcat. Luckly the source code of that class is still present in the source distribution of Tomcat. Simply it isn’t included in the build process if you don’t have the JavaMail and the JavaBeans Activation Framework in the build classpath. So I re-built the naming-factory.jar file and substituted in common/lib.

You can rebuild your own JAR, or download my new naming-factory.jar.

I discovered this problem (bug?) installing LifeRay 4.1.2 using the WAR distribution. On the contrary the LifeRay-Tomcat bundle contains the correct naming-factory.jar yet. The LifeRay error in this case is more obscure. It reports a javax.naming.NameNotFoundException: Name mail is not bound in this Context! Of course the JNDI Resource is correctly configured. This happens because LifeRay try to guess the JNDI name of the resource, that changes for the different application servers. So that exception comes from one of the attempts, and the real problem is lost and hidden. So, if you’ll see a such message, don’t spend time re-re-re-configuring your JNDI resources…but patch Tomcat!

Un DAO in DUE minuti

Lucio Benfante — Sat, 09 Dec 2006 06:40:00 -0600

Parancoe è un framework Web pensato per scrivere rapidamente applicazioni Web “di tutti i giorni”, cioè applicazioni senza requisiti particolari, quelle che nel 90% dei casi viene richiesto di sviluppare. Lo scopo quindi non è avere un framework iper-flessibile, capace di adattarsi a tutti i requisiti possibili, ma un framework che renda molto semplice la vita al programmatore sviluppando quel particolare tipo di applicazioni.

Il suo modulo di persistenza segue la stessa filosofia e permette di ottenere in pochi minuti le classi per accedere ai dati (DAO - Data Access Object) dell’applicazione, memorizzati in un database relazionale.

Ad esempio, supponiamo di avere una classe persistente Person, mappata sul DB mediante Hibernate. Per ottenere il suo DAO con Parancoe è sufficiente scriverne l’interfaccia:

@Dao(entity=Person.class)
public interface PersonDao extends GenericDao<Person, Long> {}

…e scriverne una semplice configurazione per Spring:

<parancoe:dao id="personDao"
    interface="org.parancoe.example.dao.PersonDao"/>

Già così avete ottenuto un DAO con i seguenti metodi:

Long create(Person newInstance);
Person read(Long id);
void update(Person transientObject);
void delete(Person persistentObject);

Notate che non sono metodi “generici”, ma usano il tipo dell’oggetto persistente, quindi non sono necessari cast.

Ma si può andare oltre. Supponiamo che abbiate bisogno di un metodo per ottenere la lista delle persone con un determinato nome e cognome. Con Parancoe è sufficiente modificare l’interfaccia, aggiungendo tale metodo:

@Dao(entity=Person.class)
public interface PersonDao extends GenericDao<Person, Long> {
    List<Person> findByFirstNameAndLastName(
        String firstName, String lastName);
}

Questo è tutto: non è necessario scrivere l’implementazione di tale metodo, nè modificare la configurazione del DAO.

Per saperne di più leggete questo tutorial nel wiki del progetto.

Se poi volete contribuire, anche solo per dare suggerimenti su come proseguire nello sviluppo, commentate questo articolo e visitate il sito del progetto:

http://parancoe.dev.java.net

Potete anche iscrivervi alle mailing-list del progetto:

https://parancoe.dev.java.net/servlets/ProjectMailingListList

Aggiornato 28/12/2006: è cambiato il modo di configurare i bean DAO.

Java 7

Andrea Nasato — Wed, 13 Sep 2006 12:55:00 -0500

No, non avete letto male, non è ancora uscita la release ufficiale di Java 6, che già si pensa a cosa inserire in Java 7.

In questi giorni si è aperta nella blogosfera che ruota attorno a Java una piccola guerra di religione sulla necessità o meno di inserire le chiusure nel linguaggio.

Per chi è avezzo di Smalltalk, Ruby o anche C# il concetto di chiusura è familiare. Per chi invece ha visto solo Java, il concetto è nuovo (o quasi).

Brevemente un closure è una funzione dichiarata all’interno di un’altra funzione della quale condivide le variabili. Neil Gafter (già co-autore del Collection Framework) propone che questo tipo di costrutto sia inserito anche all’interno di Java.

Il concetto non è completamente nuovo perché in Java esistono già dei costrutti simili, le classi interne anonime, che svolgono grossomodo lo stesso compito, con due differenze, secondo Gafter, importanti:

Le classi interne anonime possono lavorare con variabili del metodo che le contiene solo se queste sono dichiarate final.
La sintassi che si ottiene con le chiusure è più semplice e pulita.

Vediamo un piccolo esempio del secondo punto. Supponiamo di avere un metodo che ha il compito di sottomettere un task ad un altro thread (usando java.util.concurrent.Executor).

Con le classi anonime scriveremmo il seguente codice:

void sayHelloInAnotherThread(Executor ex) {
    ex.execute(new Runnable() {
        public void run() {
            System.out.println("hello");
        }
    });
}

mentre con le chiusure potremmo scrivere (la sintassi è ancora oggetto di discussione):

void sayHelloInAnotherThread(Executor ex) {
    ex.execute(() {
        System.out.println("hello");
    });
}

La questione è aperta. Anche James Gosling ha espresso dubbi circa la vera utilità di tale feature.

Staremo a vedere.

Bug storico...

Lucio Benfante — Fri, 16 Jun 2006 07:03:00 -0500

...presente nel JDK, e probabilmente nella maggior parte delle implementazioni di algoritmi con approccio “divide et impera”.

Quanti di noi non hanno mai scritto questa semplice e innocente riga di codice (con low e high di tipo int)?

int mid = (low+high)/2;

Il problema è che la somma dei due interi può risultare in un overflow…gosh…

L’implementazione corretta sarebbe qualcosa di simile a:

int mid = low + ((high-low)/2);

Provate a cercare in qualunque libro di algoritmi e vedrete che anche i grandi sbagliano. Io ho guardato in ‘The Art of Computer Programming’), e anche l’implementazione dell’algoritmo di ricerca binaria di Donald E. Knuth soffre dello stesso bug.

Per quanto riguarda il JDK, il bug si trova (almeno) nel metodo binarySearch della classe java.utils.Arrays. A me non è mai capitato, ma ve l’immaginate la sorpresa (per non dire altro) di vedervi sollevare un ArrayIndexOutOfBoundsException da un metodo di quella classe?

L’annuncio e la discussione del bug li fa lo stesso autore della classe, Josh Bloch, in questo blog.