Java Programming

Google Visualization API

2009-09-07T16:48:00.001+02:00

Google mette a disposizione degli sviluppatori di applicazioni web una serie di API AJAX liberamente utilizzabili all'interno delle pagine HTML. Tali API permettono di arricchire in modo semplice le funzionalita di una pagina, per esempio, aggiungere mappe (Google Maps API), inserire la funzione di ricerca di google (Google AJAX Search API) oppure un meccanismo di traduzione all'interno delle proprie pagine web tramite Google AJAX Language API. E' disponibile una lista completa di tutte le AJAX API di google.

Le Google Visualization API, appartenenti anch'esse alle Google AJAX API, permettono di creare e visualizzare in modo molto semplice grafici di reportistica relativi a dati presenti in una qualsiasi sorgente di dati accessibile tramite il web e compatibile con le Visualization API. I dati da visualizzare possono essere strutturati in grafici, tabelle, mappe, grafi, etc...

Tali oggetti possono eventualmente catturare eventi, per esempio il click del mouse, e contenere dei link, permettendo di creare pagine ricche e interattive.
Per utilizzare le Visualization API è necessario seguire alcuni semplici passi:

1) Importare, nella sezione <head> della nostra pagina web, tramite il tag <script> il file JavaScript http://www.google.com/jsapi che definisce il 'core' delle Google AJAX API:

<html>
 <head>
  <script type="text/javascript" src="http://www.google.com/jsapi"></script>
  ...
 </head>
 <body>
  ...
 </body>
</html>

2) Caricare, sempre nella sezione <head> della nostra pagina web, tramite il tag <script> le Google Visualization API e definire il tipo di visualizzazione che si vuole usare (es.: grafici a torta, grafici a barre, mappe, ...)

<html>
 <head>
  <script type="text/javascript">
   //Carica le Visualization API e la visualizzazione a grafico di torta di Google
   google.load('visualization', '1', {'packages':['piechart']});
  </script>
  <!--Carica la visualizzazione messa a disposizione da altri sviluppatori-->
  <script type="text/javascript" src="http://www.example.com/fabulous_extension.js"></script>
  ... 
 </head>
 <body>
  ...
 </body>
</html>

3) Registrare un gestore di inizializzazione e visualizzazione di dati tramite una funzione che si occupa di (usando la funzione onLoad()):

preparare i dati da visualizzare: ad ogni oggetto Visualization è associato un oggetto (di tipo DataTable ) che contiene 'fisicamente' i dati da visualizare. Un DataTable è una tabella bidimensionale, con righe, colonne e celle. Tutte le celle di una stessa colonna devono contenere dati omogenei (tipicamente stringhe o numeri)

        var data = new google.visualization.DataTable();
        // Declare columns and rows.
        data.addColumn('string', 'Task');  // Column 0 is type string and has label "Task".
        data.addColumn('number', 'Hours per Day'); // Column 1 is type number and has label "Hours per Day".
        
        // Add data.
        data.addRows([
          ['Work', 11],
          ['Eat', 2],
          ['Commute', 2],
          ['Watch TV', 2],
          ['Sleep', 7]
          ]);

creare un istanza dell'oggetto Visualization (nel seguente listato 'chart_div' è l'ID del <div> all'interno della pagina HTML in cui verra posizionato l'oggetto visualization, <div id="chart_div"> </div>)

var chart = new google.visualization.PieChart(document.getElementById('chart_div'));

registrare e ricevere eventi: tali eventi possono essere generati dall'utente, per esempio click o passaggio del mouse, oppure automatici, generati per esempio da un timer

visualizzare i dati (è possbile definire alcune proprieta dell'immagine visualizzata, per esempio il titolo e le dimensioni)

chart.draw(data, {width: 400, height: 240, is3D: true, title: 'My Daily Activities'});

4) visualizzare eventuali messaggi di errori in modo 'user-friendly' (ulteriori dettagli sulla visualizzazione di messaggi di errore).

Google Kaptcha

2009-06-26T16:31:00.001+02:00

Nell'ambito dell'informatica con il termine captcha ("Completely Automated Public Turing test to tell Computers and Humans Apart") si intende un test volto a determinare se l'utente di un sistema informatico è un umano o un computer (comunemente detto 'bot'). Un test captcha tipicamente utilizzato è quello in cui si richiede ad un utente di scrivere quali siano le lettere o numeri presenti in una sequenza di lettere o numeri che appaiono distorti o offuscati sullo schermo (operaizone difficile, anche se non impossibile, per un bot).

Nello sviluppo di un applicazione web può essere utile prevedere un test captcha per esempio quando si vuole evitare che un sistema automatico crei degli account fittizzi per un sistema informatico riempendo delle form attraverso un bot.
Google mette a disposizione degli sviluppatori WEB java (JSP) delle librerie pronte all'uso che implementano un meccanismo di captcha. L'uso basico di tali librerie è molto semplice:

occorre innanzitutto aggiungere delle librerie all'applicazione web, nella cartella WEB-INF/lib del file .war,
inserire all'interno della form un tag <img src="..."> il cui valore src matcha con l'url-pattern relativo alla servlet com.google.code.kaptcha.servlet.KaptchaServlet definito nel web.xml

creare un riferimento alla servlet kaptcha nel descrittore web.xml,

<servlet>
        <servlet-name>Kaptcha</servlet-name>
        <servlet-class>com.google.code.kaptcha.servlet.KaptchaServlet</servlet-class>
</servlet>
<servlet-mapping>
        <servlet-name>Kaptcha</servlet-name>
        <url-pattern>/kaptcha.jpg</url-pattern>
</servlet-mapping>

controllare, all'interno della servlet che gestisce i valori inviati con la form, che il valore captcha generato e messo all'interno della sessione web corrisponda con il valore inviato attraverso la form.

String kaptchaExpected = (String)request.getSession()
    .getAttribute(com.google.code.kaptcha.Constants.KAPTCHA_SESSION_KEY);
String kaptchaReceived = request.getParameter("kaptcha");

if (kaptchaReceived == null || !kaptchaReceived.equalsIgnoreCase(kaptchaExpected))
{
    setError("kaptcha", "Invalid validation code.");
}

E' possbile aumentare la complessita dell'immagine generata settando opportunamente alcuni parametri (http://code.google.com/p/kaptcha/wiki/ConfigParameters) nel file web.xml:

<init-param>
<param-name>kaptcha.border</param-name>
<param-value>yes</param-value>
</init-param>

URL correlati:
http://code.google.com/p/kaptcha/wiki/HowToUse

EJBTimer

2009-05-14T11:51:00.001+02:00

Gli EJB Timer sono oggetti tipicamente creati da stateless o message-drive session bean (la creazione all'interno di uno statefull session bean genera IllegalStateException). Per creare un oggetto Timer è necessario seguire i seguenti passi:

Ottenere un riferimento all'oggetto EJBContext (SessionContext e MessageDrivenContext rispettivamente per gli stateless e message-driven bean)
Ottenere un riferimento a TimerService attraverso l'EJBContext del punto precedente
Creare il Timer attraverso TimerService

1. Ottenere un riferimento all'EJBContext:
Le specifiche EJB 3.0 permettono di ottenere tale riferimento attraverso la tecnica della Dependency Injection

@Resource
private SessionContext sessionCtx;
@Resource
private MessageDrivenContext messageDrivenCtx;

Quando il container crea un' istanza di un enterprise bean processa tutte le relative annotazioni ed esegue le Dependency Injection. Quindi il risultato è che i riferimenti di sessionCtx e messageDrivenCtx sono popolati con un istanza rispettivamente di SessionContext e MessageDrivenContext.

2. Ottenre un riferimento a TimerService:
Questa è un'operazione relativamente semplice e intuitiva

TimerService timerService = sessionCtx.getTimerService();
TimerService timerService = messageDrivenCtx.getTimerService();

3. Creazione del Timer:
Esistono due tipologie di Timer: ad azione singola e ad intervallo, a seconda delle esigenze

Calendar now = Calendar.getInstance();
Timer singleExpirationTimer = timerService.createTimer(now.getTimeInMillis() + (10 * 1000), null);
long oneWeek = (7 * 24 * 60 * 60 * 1000);
Timer intervalExpirationTimer = timerService.createTimer(firstMarch2007, oneWeek, null);

Un timer può essere eliminato nei seguenit casi:

invocando esplicitamente il metodo di eliminazione: timer.cancel();
quando il tempo di scedulazione scade (per i Timer ad azione singola)

I timer sono degli oggetti persistenti gestiti da un DBMS la cui creazione e cancellazione avvengono all'interno di una transazione, per cui se tale transazione va in roll-back anche la creazione o cancellazione viene annullata.
La tabella di gestione dei timer deve necessariamente definire una tabella EJB__TIMER__TBL (tipicamente Glassfish, l'application server di riferimento della SUN, usa un DBMS Derby) definita dal seguente listato SQL:

CREATE TABLE EJB__TIMER__TBL (
CREATIONTIMERAW      BIGINT        NOT NULL,
BLOB                 BLOB(2G)               ,
TIMERID              VARCHAR(255)   NOT NULL,
CONTAINERID          BIGINT        NOT NULL,
OWNERID              VARCHAR(255)   NOT NULL,
STATE                INTEGER         NOT NULL,
PKHASHCODE           INTEGER         NOT NULL,
INTERVALDURATION     BIGINT          NOT NULL,
INITIALEXPIRATIONRAW BIGINT        NOT NULL,
LASTEXPIRATIONRAW    BIGINT        NOT NULL,
CONSTRAINT PK_EJB__TIMER__TBL PRIMARY KEY (TIMERID)
) ;

Può essere necessario tuttavia definire un database su un altro DBMS, per esempio MySQL, quando si vuole gestire uno stesso timer da parte di due o piu Application Server che operano all'interno di un cluster.
Per fare cio è necessario:

creare un connection pool (mysqltimerpool) che faccia riferimento al database creato su MySQL

creare una risorsa JDBC (mysqltimer) relativa al connection pool del punto precedente

istruire il container circa la risorsa JDBC da usare per la gestione del Timer Service

http://www.javabeat.net/articles/3-ejb-30-timer-services-an-overview-2.html

Virtual Hosting

2009-03-28T16:55:00.001+01:00

Il Virtual Hosting (o Shared IP Hosting) è la tecnica che permette di avere più siti web (domini) in esecuzione su una singolo web server fisico, con un unico indirizzo IP statico a disposizione. Nel virtual hosting basato sui nomi di dominio (name-based), esiste una relazione biunivoca tra host-name (dominio) e virtual server, e le richieste in arrivo al server fisico vengono instradate opportunamente ad un particolare virtual server, in base all'host name definito nell'URL di richiesta. L' URL di richiesta è l'URL usato da uno User-Agent per richiedere ad un server una risorsa; in genere un web server può risopndere a richieste con URL di richiesta differenti (e tipicamente si tiene traccia di tali URL nel file di log delle richieste). Le seguenti due richieste hanno URL request differente, anche se la risposta sarà probabilmente la stessa:

Consideriamo la seguente tabella di mapping delle richieste in arrivo all'IP 127.0.0.1:

Protocollo	Dominio	Porta	Virtual Server
http	localhost	80	server
http	localhost1	81	server1

In un contesto JEE, disponendo per esempio di un server Glassfish, sarà sufficiente inserire nel file <glassfish-domain-path>/config/domain.xml quanto segue:

...
<http-listener id="http-listener-80" port"80">
<http-listener id="http-listener-81" port"81">
...
<virtual-server id="server" hosts="localhost" http-listeners="http-listener-80">
<virtual-server id="server1" hosts="localhost1" http-listeners="http-listener-81">
...

Tramite la console di amministrazione di Glassfish è facimente possibile creare nuovi http-listener

e virtual server:

Data la configurazione della tabella precedente, per una richiesta "http://localhost1" il server restituisce HTTP-CODE=404(risorsa non trovata), perchè tutte le richieste http in arrivo sulla porta 80(quella di default per le richieste http) vengono intercettate da http-listener-80 e non esiste un binding tra questo http-listener e il virtual server server1, che serve tutte e solo le richieste le cui URL request sono del tipo "http://localhost1:81/...".

Su un computer locale è possibile sperimentare tale situazione.
In ambiente Windows il file <WINDOWS_PATH>\system32\drivers\etc\hosts, che ha funzioni molto simili a quelle del DNS, opportunamente configurato permette di instradare tutte le richieste di tipo "<PROTOCOLLO>://localhost" e "<PROTOCOLLO>://localhost1" sull'host il cui IP è 127.0.0.1, cioè il computer locale:

in genere la riga "127.0.0.1 localhost" viene inserita di default in fase di installazione del S.O., quindi per il nostro esempio è sufficiente inserire la riga evidenziata in giallo.

In fase di deploy di un applicazione web (o enterprise) tramite la console di amministrazione è possibile specificare su quale virtual server debba essere deployata un'applicazione:

In altrenativa è possibile usare il comando asadmin deploy con l opzione --virtualservers, come riportato nella documentazione ufficiale. Per chi usa ambienti di sviluppo integrato è possibile effettuare il deploy direttamente su un particolare virtual server. Per esempio, usando Netbeans IDE e sfruttando le potenzialità di ANT, è possibile modificare il file <project-home>/nbproject/ant-deploy.xml inserendo un attributo nella tag <sun-appserv-deploy>:

Settando in maniera opportuna le proprietà di un virtual server è possibile, tra l'altro, impedire l'accesso a tale virtual server (e quindi a tutte le applicazioni in esecuzione su di esso) alle richieste provenienti da particolari indirizzi IP, attraverso le proprietà denyRemoteAddress e allowRemoteAddress.

Ulteriori dettagli sull'utilizzo dei virtual server in ambiente JEE:
http://docs.sun.com/app/docs/doc/820-4507/abhfg?a=view
http://blogs.sun.com/jluehe/entry/virtual_hosting_features_in_glassfish

Inserire immagine favicon

2009-03-23T11:25:00.001+01:00

In questo articolo ci occupiamo di come definire una favicon per un'applicazione web scritta in java. La favicon è la piccola immagine che viene visualizzata sul browser nella barra degli indirizzi a sinistra di un URL e che facilita l'individuazione del nostro sito quando viene aggiunto ai preferiti. Un classico esempio di favicon è l'icona che compare a sinisra dell' URL quando si accede alla home page di google.

Per rendere disponibile e visibile tale icona dobbiamo rispettare le seguenti specifiche:

il nome dell'immagine deve essere favicon.ico (non è sufficiente rinominare una gif, bmp, o altro, ma bisogna necessariamente disporre di un programma specifico per la generazione di immagini con estensione .ico, per esempio irfanview, liberamente scaricabile)
avere dimensioni 16x16 pixel

l'immagine deve essere disponibile all'URL http://<miosito.it>/favicon.ico. Per esempio se si usa Glassfish, l'application server realizzato da Sun Microsystems come implementazione di riferimento della specifica Java EE 5, bisognerà collocare l'icona in <glassfish_domain_path>\docroot, e non semplicemente nella root della nostra applicazione. L'icona sarà applicata a tutte le applicazioni che girano sul dominio glassfish_domain_path.

In alternativa, soprattutto se si vuole definire una favicon diversa per ognua delle applicazioni definite nello stesso dominio, nella sezione <head> delle pagine web in cui si voglia visualizzare la favicon deve essere inserita una tag link con attributi rel e href opportunamente definiti, al seguente modo:

Per evitare l'operazione ripetitiva di dover definire in ogni pagina la tag link, è possibile utilizzare il meccanismo delle proprieta di gruppo di JSP(mediante <jsp-property-group> in web.xml). Per come abbiamo definito il contenuto di href nel nostro esempio è necessario che il file favicon.ico ora si trovi nella root della nostra applicazione, ma è comunque possibile collocare il file anche in una sottodirectory, per esempio /res, cambiando adeguatamente il valore di href:

Trattandosi di un'icona è opportuno, ma non necessario, istruire il container circa il mime-type del file favicon.ico. In un contesto di programmazione java lato server ciò si traduce nell'aggiunta di un nuovo <mime-mapping> nel descrittore web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="..." xmlns:xsi="..." xsi:schemaLocation="...">
    .....
    <mime-mapping>
        <extension>ico</extension>
        <mime-type>image/x-icon</mime-type>
    </mime-mapping>
</web-app>

Java Reflection

2009-02-14T16:15:00.001+01:00

Java Reflection

La reflection permette di esaminare o modificare il comportamento run-time di un applicazione java eseguita nella JVM. Questa proprietà avanzata è applicata, tra l'altro, nei seguenti casi:

Caratteristiche di estensibilita: un'applicazione può fare uso di classi esterne definite dall'utente, creando istanze si esse usando il "fully-qualified" path.
Ambienti di sviluppo visuale (IDE): generalmente gli ambienti di sviluppo visuale (p.e. NetBeans o Eclipse), che richiedono la presenza di un 'browser' di classi, per aiutare gli sviluppatori a scrivere codice corretto e semplice fanno largo uso della reflection, molto utile quando di vuole enumerare i membri di una classe.
Debug e test: i debugger necessitano di conoscere i membri privati di una classe, per determinarne il valore in un determinato istante.

La reflection è uno strumento molto potente ma che dovrebbe essere usato con cautela; in genere se è possibile raggiungere un obiettivo senza l'uso della reflection, è preferibile non farne uso. In particolare è necessario tener presente i seguenti svantaggi:

Overhead delle prestazioni: considerando che la reflection comporta la risoluzione dei tipi dinamicamente, alcune ottimizzazioni fatte dalla JVM non possono essere effettuate, per cui l'uso della reflection è sconsigliato nelle sezioni di codice che sono richiamate frequentemente nelle applicazioni performance-sensitive.
Restrizioni di sicurezza: la reflection richiede permessi di sicurezza che non sono presenti quando l'esecuzione di un applicazione avviene in presenza di un security manager. Di questo particolare bisogna tener conto per esempio nello sviluppo di un'Applet.
Esposizione dei membri interni: considerando che la reflection permette di effettuare operazioni 'illegali', per esempio accesso ai campi e metodi privati di un oggetto, si potrebbe rischiare di compromettere la portabilità del codice. In particolare viene eliminato il concetto di astrazione con conseguenti problemi in seguito ad upgrade della piattaforma.

Attraverso la reflection è possibile conoscere a run-time tutti i metodi di una classe ed eventualmente invocarne uno. Il seguente listato permette di invocare il metodo di una classe con opportuni parametri, senza che siano noti a priori il numero e tipo dei parametri:

package test;

import java.lang.reflect.*;
import java.util.Hashtable;

public class ReflectionTest {

    public static void main(String args[])
            throws Exception {
        Class classe = Class.forName(args[0]);
        String methodName = args[1];
        Method[] methods = classe.getDeclaredMethods();
        Hashtable<String, Method> methodHashtable =
                new Hashtable<String, Method>();
        for (int i = 0; i < methods.length; i++) {
            Method method = methods[i];
            String name = method.getName();
            methodHashtable.put(name, method);
        }
        Method m = methodHashtable.get(methodName);
        Class[] paramTypes = m.getParameterTypes();
        if (paramTypes.length != args.length - 2) {
            System.out.println("Num. parametri errato");
            System.exit(0);
        }
        int paramNum = paramTypes.length;
        Object[] params = new Object[paramNum];
        for (int j = 0; j < paramNum; j++) {
            Class type = paramTypes[j];
            Constructor c =
                    type.getConstructor(String.class);
            params[j] = c.newInstance(args[j + 2]);
        }
        System.out.println(m.invoke(classe.newInstance(), params));
    }
}

class ReflectionTestClass {

    public Integer sum(Integer i, Integer j) {
        return i + j;
    }
}

Il main si richiama con la sintassi "java ReflectionTest <nomeClasse> <nomeMetodo> <parametro1> <parametro2> ...", per esempio "java test.ReflectionTest test.ReflectionTestClass sum 2 3"

Primi passi con java

2009-01-26T09:57:00.001+01:00

Installazione

Le seguenti istruzioni riguardano l'istallazione della JDK vesione 1.6.0_x(in seguito jdk1.6.0_<version>) su Windows:

Scaricare la versione più aggiornata della Java SE Development Kit
Eseguire l'istallazione attraverso il file jdk-6u1<version>-windows-i586-i.exe. Durante l'installazione è possibile confermare i valori default cliccando su "Next" e "Yes". Al termine dell'istallazione potrebbe essere richiesto di riavviare il sistema. Per verificare la corretta installazione è possibile controllare che l'albero delle directory abbia la seguente struttura:
Aggiornare la variabile d'ambiente PATH (Opzionale): è possibille settare opzionalmente la variabile PATH se si vuole usare gli eseguibili della JDK (javac.exe, java.exe, javadoc.exe,...) a partire da qualsiasi directory senza specificarne ogni volta il path completo. Nel caso in cui la PATH non viene aggiornata, ogni volta che si vuole compilare un programma java è necessario, per esempio, eseguire quanto segue:

C:> "\Program Files\Java\jdk1.6.0_<version>\bin\javac" MyClass.java

a meno che non ci si trovi nella cartella C:> Program Files\Java\jdk1.6.0_<version>\bin\. In genere, quando viene eseguito un comando, Windows verifica se tale comando "si trovi" in una delle directory specificate nella variabile PATH, per cui se il percorso della directory che contiene javac viene registrato nella variabile PATH è possibile eseguire semplicemente:

javac MyClass.java

ed evitare che cosi venga visualizzato il seguente messaggio:

"jevac" non è riconosciuto come comando interno o esterno, un programma eseguibile o un file batch.

Per settare la variabile è necessario

cliccare Start > Pannello di Controllo > Sistema (su Windows XP) o Start > Setting > Pannello di Controllo > Sistema su Windows 2000

cliccare Avanzate > Variabili d'Ambiente

Settare nella variabile PATH delle 'Variabili Utente' il percorso della directory in cui si trovano gli eseguibili java.exe, javac.exe, ..., se il vecchio valore di PATH è non vuoto è necessario aggiungere ';' e poi il percorso della director, es.:

'vecchio_valore_di_PATH; C:\Program Files\Java\jdk1.6.0_<version>\bin'

Oltre alla JDK è consigliabile (per principianti ed esperti) eseguire il download della documentazione delle API in formato html e tenerla sempre a portata di mano.

Il primo programma

Il primo passo per eseguire un programma java è quello di creare un file sorgente (per esempio MyFirstClass.java). Un file sorgente java è un file di testo con estensione .java creabile e modificabile utilizzando un qualsiasi editor di testi (es. Vi per Linux o NotePad per Windows).

public class MyFirstClass {
public static void main(String[] args){

System.out.println("Il primo programma!!!");

}
}

Dopo aver salvato il file MyFirstClass.java in C:\corsojava\ (facendo attenzione alle maiuscole e minuscole, perchè Java è case-sensitive) la fase sucessiva prevede che il file sorgente venga dato in pasto al compilatore Java (attraverso il comando javac):

C:\corsojava> javac MyFirstClass.java

Il sorgente java è cosi tradotto in istruzioni in formato di basso livello universale(bytecode), eseguibili da qualsiasi Java Virtual Machine(JVM). Tali istruzioni vengono salvate in un file con estensiopne .class (MyFirstClass.class) è cosi possibile eseguire il primo programma.

C:\corsojava> java MyFirstClass

con il seguente risultato:

Il bytecode generato è indipendente dalla piattaforma HW/SW utilizzata, sarà compito della JWM tradurre il bytecode, una istruzione alla volta, in istruzioni macchina compatibili con la piattaforma utilizzata. Da questa importante proprieta di cui la programmazione java derivano i seguenti concetti:

Portabilità: il codice Java sviluppato su una piattaforma può essere trasferito senza particolari problemi su un altra piattaforma (es. da Windows a Linux). Ciò è garantito quasi al 100% poichè le JVM sviluppate per i vari sistemi operativi hanno un comportamento pressochè uniforme. Tale uniformità di funzionamento non è tuttavia garantita per le JVM implementate per i dispositivi di telefonia mobile di ultima generazione che supportano java.
Migrazione/mobilità: è possibile eseguire in locale codice java situato su siti remoti accessibili tramite la rete Internet caricandolo il in locale "al volo", senza preoccuparsi per esempio del S.O. su cui dovrà essere eseguito tale bytecode.

Si noti che l'interprete non prende in pasto un file (per l'esempio precedente non abbiamo eseguito il comando java MyFirstClass!) bensì il nome di una classe, che deve coincidere con il nome del file .class che contiene il bytecode della nostra classe.

Un programma che usa API standard

In genere un programma java fa uso di diverse classi (appartenenti alle API standard di java, definite dall'utente oppure appartenenti ad API non standard). Le classi sono raggruppate in librerie, chiamate package. In MyFirstClass abbiamo fatto uso della classe System, che fa parte del package java.lang. Tale package è importato implicitamente in ogni programma java per cui le classi in esso definite possono essere usate direttamente (come anche la classe String).
Classi di package diversi da java.lang devono essere localizzate in maniera esplicita, importandole attraverso la direttiva di importazione la cui sintassi è la seguente:

import nome_completo_della_classe;

esempi di importazione sono

import java.util.Date;

oppure

import java.util.*;

quest'ultima istruzione permette di usare tutte le classi definite nel package java.util

Il seguente programma fa uso della classe Date definita nel package java.util e stampa l'ora corrente:

import java.util.*;
public class MySecondClass {
    public static void main(String[] args){
        /**la seguente istruzione usa
         *la classe Date definita in java.util
        * */
        System.out.println("Ora corrente: "+new Date());
    }
}

il risultato della sua esecuzione è:

Un programma che usa API non standard

Il bytecode di una classe contiene le istruzioni della classe stessa e gli eventuali riferimenti al codice di altre classi usate. Quest'ultime saranno usate dalla JVM per reperire il bytecode necessario durante l'esecuzione. Se in una classe si vuole usare un'altra classe non API è necessario, se quest'ultima non si trova all'interno della stessa directory della prima, importarla esplicitamente.
Java usa la variabile CLASSPATH, che contiene i pathname delle directory in cui si trovano i package non API. Tale variabile può essere settata allo stesso modo con cui viene settata la variabile PATH, vista in precedenza. Tuttavia la variabile CLASSPATH è tipica della JVM, a differenza di PATH che ha un uso più generico, per cui potrebbe essere necessario crearla ad hoc. Il contenuto della variabile CLASSPATH deve essere tipo:

.;C:\javalib\mio_package.jar

se in c:\javalib\mio_package.jar sono localizzati i file che definiscono il bytecode delle classi che useremo all'interno di una nuova classe. In alternativa è possibile usare, in fase di compilazione(javac) o esecuzione(java) il parametro -classpath nel seguente modo:

java -classpath c:\javalib\mio_package.jar MyThirdClass

Interpreter Design Pattern

2008-11-29T14:44:00.001+01:00

INTERPRETER DESIGN PATTERN:

Obiettivo: fornire una definizione di un macro-linguaggio e il parsing di esso in un oggetto.

Questo pattern è particolarmente indicato quando si vuole costruire un parser di stringhe personalizzato, tradurre una specifica espressione o gestire un'informazione strutturata ad albero.

Nel nostro esempio useremo il design pattern Interpreter per definire un parser di una stringa che definisce codice pseudo-sql. Nel listato, per focalizzare l'attenzione sul pattern in esame e quindi definire un codice snello, faremo uso anche dei pattern Visit e Iterator.

package designPatterns.interpreter.*;
import java.util.*;

public class Main {
    public static void main(String[] args) {
         String source = "attributes='id',table='users',"+
                 "conditions='username\"root\" and password=\"mypwd\"'";
         String delimiter = "=,'";
         Parser parser = new Parser(source, delimiter);
         parser.myParser();
         parser.interpret();
         String result = parser.getInterpretedResult();
         System.out.println(result);
     }
}

class Parser{
    private String expression;
    private String delimitator;
    private List result;
    private String interpreted;
    public Parser(String e, String t) {
       expression = e;
       delimitator = t;
    }
    public void myParser() {
        StringTokenizer holder = new StringTokenizer(expression, delimitator);
        String[] toBeMatched = new String[holder.countTokens()];
        int idx = 0;
        while(holder.hasMoreTokens()) {
            String item = holder.nextToken();
            int start = item.indexOf(",");
            if(start==0) {
               item = item.substring(2);
            }
        toBeMatched[idx] = item;
        idx ++;
        }
        result = Arrays.asList(toBeMatched);
     }
     public List getParseResult() {
        return result;
     }
     public void interpret() {
         StringBuffer buffer = new StringBuffer();
         ListIterator list = result.listIterator();
         while (list.hasNext()){
            String token = (String)list.next();
            if (token.equals("attributes")){
               token = "SELECT";
            }else if(token.equals("table")) {
               token = "FROM";
            }else if(token.equals("conditions")) {
               token = "WHERE";
            }
            buffer.append(" " + token);
         }
         interpreted = buffer.toString();
     }
     public String getInterpretedResult() {
        return interpreted;
     }
}

Un esempio molto più concreto di applicazione del pattern Interpreter è dato dal parsing di una query scritta in linguaggio EJB-QL nell'ambito dello sviluppo JEE. Come noto una query di ricerca scritta in tale linguaggio non è altro che una stringa ma il risultato della sua esecuzione, mediante l'utilizzo delle API che gestiscono la persistenza con un database, è un vero e proprio oggetto o una collezione di tali oggetti omogenei. Nel seguente listato viene illustrata una semplificazione del parser che, data una query ejb-ql, restituisce una collezione di oggetti (che saranno poi gli Entity Bean deputati a gestire la persistenza delle informazioni elaborate in un'applicazione enterprise con un database).

package designPatterns.interpreter;
import java.util.*;

public class Main {
    public static void main(String[] args)
            throws NotWellFormedSimpleQuery {
        //String to parse
         String queryString = "FROM interpreter.MyEntity";
         SimpleEJBQueryParser queryParser =
                 new SimpleEJBQueryParser(queryString);
         //interpret String and cast result
         List<MyEntity> resultList =
                   (List<MyEntity>) queryParser.getResultList();
         Iterator it = resultList.iterator();
         while(it.hasNext()){
            MyEntity tmp = (MyEntity)it.next();
            System.out.println(tmp.getId()+"-"+tmp.getValue());
         }
     }
}

class MyEntity{
    private Integer id;
    private String value;
    public MyEntity(){}
    public MyEntity(Integer id, String value) {
        this.id = id;
        this.value = value;
    }
    public void setId(Integer id) {
        this.id = id;
    }
    public void setValue(String value) {
        this.value = value;
    }
    public Integer getId() {
        return id;
    }
    public String getValue() {
        return value;
    }
}

class SimpleEJBQueryParser{
    private Class entityClass;
    private String tableName;
    private List resultList;
    public SimpleEJBQueryParser(String query)
            throws NotWellFormedSimpleQuery{
        StringTokenizer st = new StringTokenizer(query);
        if(!st.nextToken(" ").trim().equals("FROM"))
            throw new NotWellFormedSimpleQuery();
        tableName = st.nextToken(" ");
        try {
            entityClass = Class.forName(tableName);
        } catch (ClassNotFoundException ex) {
            throw new NotWellFormedSimpleQuery(ex.toString());
        }
    }
    public List getResultList(){
        buildResultList();
        return resultList;
    }
    private void buildResultList(){
        resultList = new ArrayList();
        Object obj = null;
        try {
            obj = entityClass.newInstance();
        } catch (Exception ex) {
            System.out.println(ex.toString());
        }
        if(obj instanceof MyEntity){
            MyEntity tmp = (MyEntity)obj;
            /*populate MyEntity directly or setting values
            /*from database table MyEntity for examle:*/
            tmp.setId(1);
            tmp.setValue("ciao");
        }
        resultList.add(obj);
    }
}

class NotWellFormedSimpleQuery extends Exception {
    public NotWellFormedSimpleQuery(){
        super("The simple query is not well formed");
    }
    public NotWellFormedSimpleQuery(String msg){
        super(msg);
    }
}

Chain-Of-Responsability Design Pattern

2008-11-28T15:17:00.007+01:00

CHAIN-OF-RESPONSABILITY DESIGN PATTERN:

Obiettivo: fare in modo che una richiesta possa essere processata da uno di più oggetti. Tale richiesta passa per una catena di oggetti finchè uno di essi non la gestisce.

Il può noto esempio di applicazione di questo design pattern è la gestione delle eccezioni in java. Quando durante l'esecuzione del metodo di una classe scatta un'eccezione, la classe può gestirela (tramite il meccanismo try-catch) o delegarne la responsabilità della gestione alla classe che ha invocato il metodo(tramite il costrutto throws). Quest'ultima classe può gestirla o a sua volta sollevare l'eccezione alla classe da cui è stata invocata. Un altro esempio di utilizzo di questo design pattern è quello dell'utilizzo della classe javax.servlet.Filter in un'applicazione web. Il metodo chain.doFilter() viene richiamato per fare in modo che tutti i filtri di una servlet possano processare una richiesta prima che essa venga processata dalla stessa servlet. Se un solo filtro della catena blocca la richiesta allora la richiesta viene 'annullata' dal web container.

Nel nostro esempio useremo il design pattern Chain of Responsability per creare una semplice applicazione (a scopo puramente didattico) che determina se una data nel formato ("yyyy" "mm" "dd") è corretta. I requisiti di correttezza sono che

"yyyy" "mm" "dd" rappresentino interi,
1<=mm>=12
1<=dd>=31, 1<=dd>=30 per i mesi aprile, giugno, settembre e novembre, 1<=dd>=29 se mm=02 negli anni bisestili, 1<=dd>=28 se mm=02 negli anni non bisestili

Nel seguente listato tali controlli vengono affidati ad una catena di oggetti, ognuno dei quali verifica che sia verificato un requisito specifico. Se uno solo di tali oggetti rivela che la data non è correttamente definita è inutile continuare nei controlli.

package designPatterns.chainofresponsability;

public class Main {
    public static void main(String[] args) {
        MyDate myDate = new MyDate("1981", "13", "6");
        IsNumericFilter isNumericFilter = new IsNumericFilter();
        MonthFilter monthFilter = new MonthFilter();
        DayFilter dayFilter = new DayFilter();
        isNumericFilter.doChain(monthFilter);
        monthFilter.doChain(dayFilter);
        isNumericFilter.doFilter(myDate);
    }
}

class MyDate{
    private String year;
    private String month;
    private String day;
    public MyDate(String y, String m, String d) {
        this.year = y;
        this.month = m;
        this.day = d;
    }
    public String getDay() {
        return day;
    }
    public String getMonth() {
        return month;
    }
    public String getYear() {
        return year;
    }
}

abstract class MyDateFilter{
    protected MyDateFilter successorMyDateFilter;
    protected String wrongDate = "Data non corretta";
    protected String okDate = "Data corretta!!";
    public void doChain(MyDateFilter successor){
        this.successorMyDateFilter=successor;
    }
    public abstract void doFilter(MyDate myDate);
}

class IsNumericFilter extends MyDateFilter{
    @Override
    public void doFilter(MyDate myDate) {
        if(!isNumeric(myDate.getYear()) ||
                !isNumeric(myDate.getMonth()) ||
                !isNumeric(myDate.getDay()))
            System.out.println(wrongDate);
        else
            successorMyDateFilter.doFilter(myDate);

    }
    private boolean isNumeric(String param){
        try{
            Integer.parseInt(param);
        }catch(NumberFormatException e){
            return false;
        }
        return true;
    }
}

class MonthFilter extends MyDateFilter{
    @Override
    public void doFilter(MyDate myDate) {
        String mString = myDate.getMonth();
        int month = Integer.parseInt(mString);
        if(month<1 || month>12)
            System.out.println(wrongDate);
        else
            successorMyDateFilter.doFilter(myDate);
    }
}

class DayFilter extends MyDateFilter{
    @Override
    public void doFilter(MyDate myDate) {
        String dString = myDate.getDay();
        String mString = myDate.getMonth();
        String yString = myDate.getYear();
        int year = Integer.parseInt(yString);
        int day = Integer.parseInt(dString);
        if(day<1 || day>31)
            System.out.println(wrongDate);
        else if(isShortMonth(mString) && dString.equals("31"))
            System.out.println(wrongDate);
        else if(mString.equals("2")){
            if(new java.util.GregorianCalendar().isLeapYear(year)){
                if(day>29)
                     System.out.println(wrongDate);
            }else if(day>28)
                 System.out.println(wrongDate);
        }

        else
            System.out.println(okDate);
    }
    private boolean isShortMonth(String mString){
        int month = Integer.parseInt(mString);
        if(month==4 || month==6 || month==9 || month==11)
            return true;
        return false;
    }
}

Iterator Design Pattern

2008-11-28T15:17:00.005+01:00

ITERATOR DESIGN PATTERN:

Obiettivo: fornire un meccanismo che permetta di 'esplorare' una lista di collection o oggetti aggregati senza conoscerne la rappresentazione interna.

Nel nostro esempio useremo il pattern Iterator per stampare sullo standard output una lista di stringhe.

package designPatterns.iterator;
interface StringListIterator {
    public void first();
    public void next();
    public boolean isDone();
    public String currentString();
}

class StringList {
    private String[] strings;
    private int currIndex;
    private int size;
    public StringList(int size) {
        strings = new String[size];
        currIndex = 0;
        this.size = size;
    }
    public int count() {
        return currIndex;
    }
    public void append(String titleIn) {
        if (currIndex >= size) {
            String[] tempArray = new String[size];
            for (int i = 0; i < size; i++) {
                tempArray[i] = strings[i];
            }
            strings = null;
            size = size + 1;
            strings = new String[size];
            for (int i = 0; i < size - 1; i++) {
                strings[i] = tempArray[i];
            }
        }
        strings[currIndex++] = titleIn;
    }
    public void delete(String titleIn) {
        boolean found = false;
        for (int i = 0; i < (currIndex - 1); i++) {
            if (found == false) {
                if (strings[i].equals(titleIn)) {
                    found = true;
                    strings[i] = strings[i + 1];
                }
            } else {
                if (i < (currIndex - 1)) {
                    strings[i] = strings[i + 1];
                } else {
                    strings[i] = null;
                }
            }
        }
        if (found == true) {
            --currIndex;
        }
    }
    public StringListIterator createIterator() {
        return new InnerIterator();
    }
    private class InnerIterator
            implements StringListIterator {

        private int pos = 0;

        private InnerIterator() {
        }
        public void first() {
            pos = 0;
        }
        public void next() {
            if (pos < (currIndex)) {
                ++pos;
            }
        }
        public boolean isDone() {
            if (pos >= (currIndex)) {
                return true;
            } else {
                return false;
            }
        }
        public String currentString() {
            return strings[pos];
        }
    }
}

public class Main {
    public static void main(String[] args) {
        StringList strings = new StringList(3);
        strings.append("string1");
        strings.append("string2");
        strings.append("string3");
        StringListIterator iterator =
                strings.createIterator();
        while (!iterator.isDone()) {
            String curr = iterator.currentString();
            System.out.println(curr);
            iterator.next();
        }
        strings.delete("string1");
        System.out.println(" ");
        iterator.first();
        while (!iterator.isDone()) {
            String curr = iterator.currentString();
            System.out.println(curr);
            iterator.next();
        }
    }
}

Le API standard di Java forniscono un meccanismo built-in che facilita l'uso del pattern Iterator. Ogni oggetto che implementa java.util.AbstractList (es.: Vector e ArrayList tanto per fare i nomi di due classi ampiamente usate nella programmazione java), esporta il metodo public java.util.Iterator iterator() che corrisponde, per funzionalità, al metodo public StringListIterator createIterator() della classe StringList dell'esempio appena visto. Facendo uso dell'interfaccia java.util.Iterator avremmo ottenuto il seguente listato:

import java.util.*;
public class Main {

 public static void main(String[] args) {

 ArrayList strings = new ArrayList(3);
 strings.add("string1");
 strings.add("string2");
 strings.add("string3");
 Iterator iterator = strings.iterator();
 while (iterator.hasNext()) {

 String next = (String)iterator.next();
 System.out.println(next);

 }
 strings.remove("string1");
 System.out.println(" ");
 iterator = strings.iterator();
 while (iterator.hasNext()) {

 String next = (String)iterator.next();
 System.out.println(next);

}

}

}

Si noti che, essendo Iterator una classe di uso generico (applicabile ad aggregati di Oggetti di qualsiasi tipo), è necessario effettuare il cast a String dell'Object ritornato dal metodo iterator.next(). Nel nostro esempio il cast non è necessario perchè abbiamo definito un Iterator ad hoc il cui metodo currentString() ritorna una Stringa.

Observer Design Pattern

2008-11-28T15:17:00.003+01:00

OBSERVER DESIGN PATTERN:

Obiettivo: modificare lo stato di un oggetto in conseguenza del cambiamento dello stato di un altro oggetto.

Questo pattern è usato soprattutto nelle applicazioni GUI, definendo per esempio una relazione uno-a-uno o uno-a-molti tra oggetti swing tale che quando cambia lo stato di uno, lo stato di uno o piu altri cambia in modo automatico. Nel nostro esempio useremo il Pattern Observer (noto anche come Publish-Subscribe) nella creazione di un'applicazione GUI in cui è definito un JFrame (Observer) che visualizza le stringe inserite dall'utente mediante standard input (Observable). La prima classe implementa Observer, la seconda estende Observable, due classi presenti nelle API standard in java.util.

package designPatterns.observer;

import java.io.*;
import java.util.*;
import javax.swing.*;
import java.awt.event.*;

public class Main {

    public static void main(String args[]) {
        InputConsole input = new InputConsole();
        OutputForm output = new OutputForm();
        input.addObserver(output);
        input.read();
    }
}

class OutputForm extends JFrame implements Observer {

    JTextField display;

    public OutputForm() {
        display = new JTextField(10);
        getContentPane().add(display);
        setTitle("Observer form");
        setSize(200, 100);
        setLocation(200, 100);
        setVisible(true);
        //exit when closing application
        addWindowListener(new WindowAdapter() {

            @Override
            public void windowClosing(WindowEvent e) {
                System.exit(0);
            }
        });
    }

    public void update(Observable ob, Object o) {
        if (o instanceof String) {
            String text = (String) o;
            display.setText(text);
        }
    }
}

class InputConsole extends Observable {

    public void read() {
        try {
            BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
            String inputString;
            while (!(inputString = br.readLine()).equals("exit")) {
                setChanged();
                notifyObservers(inputString);
            }
            System.exit(0);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

Adapter Design Pattern

2008-11-28T15:17:00.001+01:00

ADAPTER DESIGN PATTERN:

Obiettivo: convertire una interfaccia esistente in una nuova interfaccia per ottenere compatibilità e riusabilità di classi non correlate in un' applicazione.

Nelle API java standard le classi che implementano il pattern Adapter sono facilmente riconoscibili (WindowAdapter, ComponentAdapter, MouseAdapter,...) . Come noto l'interfaccia WindowListener ha sette metodi:

public interface Windowlistener {

 public void windowClosed(WindowEvent e);
 public void windowOpened(WindowEvent e);
 public void windowIconified(WindowEvent e);
 public void windowDeiconified(WindowEvent e);
 public void windowActivated(WindowEvent e);
 public void windowDeactivated(WindowEvent e);
 public void windowClosing(WindowEvent e);

}

Qualsiasi classe che implementa WindowListener dovrebbe necessariamente definire il contenuto di tutti questi metodi. La classe WindowAdapter implementa questa interfaccia con metodi tutti vuoti:

class WindowAdapter implements WindowListener{
    public void windowClosed(WindowEvent e){}
    public void windowOpened(WindowEvent e){}
    public void windowIconified(WindowEvent e){}
    public void windowDeiconified(WindowEvent e){}
    public void windowActivated(WindowEvent e){}
    public void windowDeactivated(WindowEvent e){}
    public void windowClosing(WindowEvent e){}
}

In questo modo in un'applicazione GUI, per esempio, una classe che ha bisogno di intercettare solo l'evento chiusura della finestra in cui è inserito un JFrame non deve implementare tutti i metodi presenti in WindowListener, ma solo il metodo public void windowClosed(WindowEvent e){} tramite la tecnica nota come Overriding.

class WindowClosingListener extends JFrame {
   public WindowClosingListener () {
        setSize(200, 200);
        setVisible(true);
        addWindowListener(new WindowAdapter() {
            @Override
            public void windowClosing(WindowEvent e) {
                System.out.println("Closing event caught");
                System.exit(0);
            }
        });
    }
    public static void main(String[] args) {
        new WindowClosingListener();
    }
}

Un'altra applicazione di questo pattern (noto anche come Wrapper) è il riuso di classi e creazione di nuove classi compatibili con quelle già esistenti. Usando la composizione, per esempio, si potrebbe 'adattare' una classe già implementata e ben testata ad un nuovo sistema. La classe Adapter dovrà dichiarare tale classe gia esistente come variabile, tramite il meccanismo della composizione, e 'wrapparla' o 'fonderla' in se stessa.

import java.util.Date;
public class DataAdapter {
    private Date date;
    public DataAdapter() {
        date = new Date();
    }
    public DataAdapter(long date) {
        this.date = new Date(date);
    }
    public void setMillisecondi(long time) {
        date.setTime(time);
    }
    public long getMillisecondi() {
        return date.getTime();
    }
    public int confronta(DataAdapter anotherDate) {
        return date.compareTo(new Date(anotherDate.getMillisecondi()));
    }
    public boolean prima(DataAdapter when) {
        return date.before(new Date(when.getMillisecondi()));
    }
    public boolean dopo(DataAdapter when) {
        return date.after(new Date(when.getMillisecondi()));
    }
    @Override
    public String toString() {
        return date.toString();
    }
}

La classe DataAdapter può essere usata nel seguente modo:

    public static void main(String args[]) {
        DataAdapter data1 = new DataAdapter(1225446691789l);
        DataAdapter data2 = new DataAdapter(1225445322893l);
        if (data1.confronta(data2) == 0) {
            System.out.println("Le date coincidono");
        } else if (data1.confronta(data2) > 0) {
            System.out.println(data1 + " > " + data2);
        } else {
            System.out.println(data1 + " < " + data2);
        }
    }

Singleton Design Pattern

2008-11-28T15:16:00.001+01:00

SINGLETON DESIGN PATTERN:

Obiettivo: avere una sola istanza di una classe o un unico valore accessibile e modificabile in tutta l'applicazione.

Questo pattern può essere usato per esempio quando si vuole avere all'interno di un'applicazione un unica classe che gestisca tutte le interazioni con il file system, un unico spooler di stampa, un unico Logger, un'unica connessione ad un DB, un unico socket di Input/Output, etc... Nel nostro esempio useremo il Pattern Singleton per avere un unica connessione ad un DB MySQL, ciò garantirà evidentemente un incremento nelle performance dell'applicazione in quanto la creazione e distruzione di una connessione ad un DB sono notoriamente operazioni dispendiose.

Per avere una classe che rispetti il pattern Singleton è necessario definire le sue variabili o metodi pubblici e/o statici, e firmare tutti i costruttori privati, per impedire alla JVM di crearne un'istanza di default. Un noto esempio di classe Singleton è java.lang.Math, la quale non estensibile.

package designPatterns.singleton;
import java.sql.*;

public class Main {

 public static void main(String[] args) throws Exception {

 DatabaseReader reader = new DatabaseReader("select ...");
 reader.request();
 DatabaseWriter writer = new DatabaseWriter("update ...");
 writer.request();
 MyDBConnector.getConnector().close();

}

}

class DatabaseReader{

 String request;
 public DatabaseReader(String request) {

 this.request = request;

 }
 public String request() throws Exception{

 String ret = "";
 MyDBConnector connector = MyDBConnector.getConnector();
 Connection conn = connector.getConnention();
 Statement st = conn.createStatement();
 ResultSet rs = st.executeQuery(request);
 //build ret according to rs
 return ret;

}

}

class DatabaseWriter{

 String request;
 public DatabaseWriter(String request) {

 this.request = request;

}

 public void request() throws Exception{
 MyDBConnector connector = MyDBConnector.getConnector();
 Connection conn = connector.getConnention();
 conn.createStatement().executeUpdate(request);

}

}

class MyDBConnector{

 private static MyDBConnector instance;
 private Connection conn;
 private static final String url = "jdbc:mysql://...";
 private static final String usr = "...";
 private static final String pwd = "...";
 private MyDBConnector() throws Exception{

 Class.forName("com.mysql.jdbc.Driver");
 conn = (Connection) DriverManager.getConnection(url,usr,pwd);

 }
 public static MyDBConnector getConnector() throws Exception {

 if(instance==null)

 instance = new MyDBConnector();

 return instance;

 }
 public Connection getConnention(){

 return conn;

 }
 public void close(){

 if(conn!=null)

 try{

 conn.close();

 }catch(Exception e){}

 instance = null;

}

}

Nel nostro caso la classe Singleton è MyDBConnector. Tale classe è non Thread-Safe infatti nel metodo public static MyDBConnector getConnector() throws Exception due o piu thread potrebbero eseguire l'istruzione instance = new MyDBConnector();. Per aggirare questo problema è buona prassi utilizzare la calusola synchronized:

public static synchronized MyDBConnector getConnector() throws Exception {...}

tuttavia questa soluzione potrebbe decrementare le performance dell'esecuzione dell'applicazione di un fattore non indifferente. E' ragionevole sincronizzare le richieste solo se l'istanza del Singleton è nulla. La soluzione definitiva è dunque:

public static MyDBConnector getConnector() throws Exception {

 if(instance==null)

 synchronized (MyDBConnector.class) {

 if(instance==null)

 instance = new MyDBConnector();

 }
 return instance;

}

Container Managed Transaction

2008-11-11T17:59:00.001+01:00

INTRODUZIONE

Nella teoria dei database si definisce transazione un programma in esecuzione (processo) che opera su un DB. Classici esempi di transazioni sono la prenotazione di un volo aereo o un bonifico bancario. La corretta prenotazione di un volo aereo richiede che:

venga prenotato un posto sull' aereo e contestualmente che venga effettuato il pagamento; se una delle due operazioni fallisce anche l'altra deve essere annullata (Atomicità),

dopo la prenotazione sia verificato, tra l'altro, chela somma dei posti liberi e quelli occupati rimanga invariata (Coerenza),

sia possibile eseguire una nuova prenotazione aerea parallelamente ad essa e che l'eventuale fallimento di quest'ultima non influisca sull'esito della nuova prenotazione (Isolamento),

dopo la prenotazione sia garantito al passeggero che il posto non venga assegnato ad un altro passeggero fino all'imbarco (Durabilità).

I quattro requisiti enumerati sono esempi di proprietà che una qualunque transazione dovrebbe avere e che sono raggruppate nell'acronimo ACID.

Atomicità: la transazione deve essere eseguita nella sua interezza o non eseguita per niente, non sono ammesse esecuzioni parziali;

Coerenza (o Consistenza): la transazione inizia e finisce trovando e lasciando il database in uno stato consistente, uno stato in cui i dati presenti nel database non violano eventuali vincoli di integrità;

Isolamento: ogni transazione deve essere eseguita in modo indipendente dalle altre e non devono essere visibili i suoi risultati intermedi. L'eventuale fallimento di una non deve influire sul buon esito delle altre;

Durabilità (o Persistenza): una volta che una transazione è finita i suoi effetti devono perdurare nel tempo.

Un discorso a parte meriterebbe la proprietà di isolamento, qui ci limitiamo solo a definire brevemente i quattro livelli previsti di isolamento con semplici esempi:

read uncommitted:

consente l'accesso in lettura, bloccando la scrittura, a dati che potrebbero essere modificati da transazioni parallele
in questo modo potrebbero verificarsi letture sporche, letture di dati che portebbero sparire in futuro se la transazione che li ha generati abortisce

per esempio consideriamo le seguenti operazioni effettuate dalle transazioni T1 e T2 in ordine cronologico:

T1	T2
insert into mytable(id, name) values('1','xxx');
	select * from mytable where id=1;
rollback

T2 ha avuto accesso ad un dato che non è mai esistito!

read committed:

prevede il rilascio dei dati in lettura, ritardando quelli in scrittura
si potrebbe verificare il problema delle letture non-ripetibili

per esempio consideriamo la seguente situazione

T1	T2
select * from mytable where id=1;
	update mytable set mycolumn=1 where id=1; commit;
select * from mytable where id=1;

due letture consecutive di una stessa riga da parte di T1 producono risultati diversi

repeatable read:

vengono bloccati gli accessi sia in lettura che in scrittura ma solo delle tuple coinvolte
si potrebbe verificare il problema dei fantasmi:

per esempio consideriamo la seguente situazione

T1	T2
select * from mytable where age betwenn 10 AND 30;
	insert into mycolumn values(1,"mario",27); commit;
select * from mytable where age betwenn 10 AND 30;

due query effettuate consecutivamente da T1 restituiscono un numero di righe diverse

serializable:

garantisce isolamento totale, come se le transazioni vengono effettuate in sequenza
poco efficiente

CONTAINER-MANAGED TRANSACTIONS (CMT)

In un session o message-driven bean si può delegare la gestione delle transazioni al EJB container. Questo facilita lo sviluppo di un EJB in quanto non bisogna definire esplicitamente quando inizia e finisce una una transazione. Tipicamente il container inizia una transazione prima di eseguire il contenuto di un metodo e la termina dopo aver eseguito l'ultima istruzione del metodo stesso. In questo modo una transazione corrisponde ad un metodo anche se non vale necessariamente il viceversa cioè che ad ogni metodo corrisponda una transazione. Negli EJB che implementano CMT non è possibile usare alcuna istruzione che interferisca con la gestione delle transazioni da parte del container, per esempio i metodi commit, setAutoCommit e rollback di java.sql.Connection e commit e rollback di javax.jms.Session. Non è inoltre posisbile usare l'interfaccia javax.transaction.UserTransaction.

Dato un metodo che definisce una transazione è possibile controllare lo scope di tale transazione attraverso degli attributi

Data una situazione in cui method-a() di Bean-1 inizia una transazione e invoca method-b() di Bean-2, a seconda delle esigenze è necessario definire un attributo di transazione per method-b(), per esempio se il container deve iniziare una nuova transazione in cui eseguire method-b().

Attributi di transazione

L'attributo di transazione può assumere uno dei seguenti valori possibili:

Required: prevede che method-b() sia eseguito all'interno della transazione creata per method-a(), se method-a() non è associato ad alcuna transazione preesistente allora il container inizia una nuova transazione prima di eseguire method-b(). Required rappresenta l'attributo di default per CMT e in genere non si specifica se non quando si ha la necessità di sovrascrivere un'altro attributo di transazione.
RequiresNew: prevede che quando method-a() invoca method-b(), il container effettui i seguenti passi:

sospende la transazione di method-a()
inizia una nuova transazione
delega la chiamata a method-b()
riesuma la transazione di method-a() dopo che method-b() è stato completato

Se method-a() non è associato ad alcuna transazione, il container inizia in ogni caso una nuova transazione prima di eseguire il method-b(). Tipicamente si usa RequiresNew quando si vuole assicurare che method-b() sia eseguito sempre all'interno di una nuova transazione

Mandatory: se method-a() ha iniziato una transazione e invoca method-b(), il metodo viene eseguito all'interno della stessa transazione, altrimenti il container solleva una TransactionRequiredException.
NotSupported: se method-a() ha iniziato una transazione prima di invocare method-b(), tale transazione viene sospesa e ripresa dopo che method-b() viene terminato. Se method-a() non ha iniziato alcuna transazione, il container non ne crea una nuova. Questo attributo viene usato quando method-b() non ha necessità di gestire una transazione. Considerando che in genere l'uso delle transazioni è molto costoso in termini di risorse, l'attributo NotSupported potrebbe incrementare le performance.
Suports: se method-a() ha iniziato una transazione prima di invocare method-b(), tale metodo viene eseguito all'interno della stessa transazione; viceversa method-b() non viene eseguito all'interno di una transazione. Considerando che il comportamento del container nell'esecuzione di method-b() può variare, è necessario usare questo attributo con molta cautela.
Never: se method-a() ha iniziato una transazione prima di invocare method-b(), il container solleva un'eccezione RemoteException, altrimenti il container non inizia una nuova transazione prima di eseguire method-b().

La seguente tabella riassume gli effetti dell'utilizzo dei vari attributi di transazione.

Transaction Attribute	Client's Transaction	Business Method's Transaction
`Required`	None	T2
`Required`	T1	T1
`RequiresNew`	None	T2
`RequiresNew`	T1	T2
`Mandatory`	None	error
`Mandatory`	T1	T1
`NotSupported`	None	None
`NotSupported`	T1	None
`Supports`	None	None
`Supports`	T1	T1
`Never`	None	None
`Never`	T1	Error

Sia T1 che T2 sono transazioni controllate dal container. La transazioe T1 è associata a un metodo method-a() di Bean-1 che invoca il metodo method-b() il quale in genere può essere definito in un nuovo EJB Bean-2. T2 viene iniziato dal container perima dell'esecuzione di method-b(). Nell'ultima colonna la parola None indica che method-b() non viene eseguito all'interno di una transazione controllata dal container. In ogni caso le chiamate a DB in tale metodo potrebbero essere controllate dal transaction manager del DBMS.

Settaggio degli attributi di transazione

Nelle specifiche EJB gli attributi di transazione vengono definite usando l'annotazione javax.ejb.TransactionAttribute, s settandola ad una delle costanti javax.ejb.TransactionAttributeType. L'annotazione può essere usata per tutta la classe o per il singolo metodo; nel primo caso il TransactionAttributeType viene applicato a tutti i business method della stessa classe. Se l'annotazione viene definita sia sulla classe che su un particolare metodo, viene applicato il TransactionAttributeType definito per il metodo, in modo tale da poter definire una regola generale per il bean e eccezioni per i singoli metodi. Di seguito viene elencato per ogni attributo di transazione il TransactionAttributeType corrispettivo:

Required: TransactionAttributeType.REQUIRED
RequireNew: TransactionAttributeType.REQUIRES_NEW
Mandatory: TransactionAttributeType.MANDATORY
NotSupported: TransactionAttributeType.NOT_SUPPORTED
Supports: TransactionAttributeType.SUPPORTS
Never: TransactionAttributeType.NEVER

Il seguente frammento di codice illustra come usare l'annotazione TransactionAttribute:

@TransactionAttribute(NOT_SUPPORTED)
@Stateful
public class TransactionBean implements Transaction {

...
@TransactionAttribute(REQUIRES_NEW)
public void firstMethod() {...}
    
@TransactionAttribute(REQUIRED)
public void secondMethod() {...}
    
public void thirdMethod() {...}
    
public void fourthMethod() {...}

}

In questo esempio, l'attributo di transazione per la classe TransactionBean è stato settato a NotSuported. Questo vuol dire che per ogni metodo dello stesso EJB, dove non specificato diversamente, vale il TransactionAttributeType NOT_SUPPORTED. firstMethod è stato settato a RequiresNew, e secondMethod è stato settato a Required. Considerando che il TransactionAttribute del metodo sovrascrive il TransactionAttribute della classe, una chiamata a firstMethod implicherà la creazione di una nuova transazione, mentre una chiamata a secondMethod implicherà che tale metodo verrà eseguito nella stessa transazione del metodo in cui avviene l'invocazione, se esiste, o in una nuova transazione, se non esiste. Le chiamate a firstMethod e firstMethod avverrano senza alcuna transazione.
Esistono due modi di effettuare il Roll-back di una transazione CMT:

attraverso un'eccezione di sistema, nel qual caso il container automaticamente effettua il roll-back della transazione,
invocando il metodo setRollbackOnly dell'interfaccia EJBContext. In questo caso il bean istruisce il container di effettuare il roll-back. Se il bean solleva una eccezione a livello si applicazione, il roll-back non è automatico, ma può essere iniziato attraverso una chiamata a setRollbackOnly.

Implementando l'interfaccia SessionSynchronization è possibile sincronizzare le variabili d'istanza di un session bean attraverso messaggi di notifica di sincronizzazione di una transazione. Per esempio, attraverso questo meccanismo, è possibile sincronizzare le variabili di un EJB con i corrispettivi valori presenti nel DB. Il container invoca i metodi afterBegin, beforeCompletion e afterCompletion, esportati dall'interfaccia SessionSynchronization ad ogni stato principale di una transazione. In particolare:

il metodo afterBegin informa l'istanza del EJB che una nuova transazione è stata iniziata; il container invoca questo metodo subito prima di eseguire il business method.
il metodo beforeCompletion viene invocato dal container appena il business method è stato completato ma prima di 'committare' la transazione. In questo modo il bean ha l'ultima opportunità di effettuare il rollback della transazione con una chiamata a setRollbackOnly.
il metodo afterCompletion indica che la transazione è stata completata. Ha un solo parametro di tipo boolean il cui valore è true se la transazione è andata a buon fine, false altrimenti.

Design Patterns

2008-11-04T11:40:00.001+01:00

Nell'Ingegneria del Software un Design Patterns può essere definito come "una soluzione progettuale generale a un problema ricorrente". Tale soluzione è language-independent e rappresenta un modello da applicare per risolvere un problema che può presentarsi in diverse situazioni durante la progettazione e lo sviluppo del software. La GOF(Gang Of Four) fu il primo gruppo di sviluppatori a pensare di definire un insieme di formalismi che permettesse di facilitare la progettazione e sviluppo del software basata su un insieme di Design Pattern. SUN suggerisce lo studio del libro scritto dalla GOF, "Design Patterns"- Elements of Reusable Object-Oriented Software, e proprio da esso si prende spunto per descrivere i seguenti Design Pattern, con esempi concreti di utilizzo implementati in Java, il piu popolare dei linguaggi OO.

La GOF ha definito un insieme di 23 Design Pattern ben noti, suddivisi in 3 grandi categorie (in rosso quelli già trattati in questo post):

-Pattern Creazionali(Singleton, Abstract Factory, Builder, Factory, Prototype)

-Pattern Strutturali(Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy)

-Pattern Comportamentali(Chain-of-responsability, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor)

Tutti i post sono work-in-progress.

...POST TO BE CONTINUED....

Upload di file

2008-10-24T11:34:00.002+02:00

Per effettuare l'upload di un file sul server è necessario utilizzare le Commons FileUpload API (http://commons.apache.org/io) e le Commmons IO API (http://commons.apache.org/fileupload); le prime forniscono un meccanismo semplice, robusto e performante di upload di file ad un'applicazione web, le seconde un supporto allo sviluppo di funzionalità Input-Output e ci serviranno per memorizzare i file uplodati sul server.

La form che ci permetterà di selezionare un file lato client sarà del tipo:

<form action="UploadFile" method="post" enctype="multipart/form-data" accept="image" maxlength="100000">

</form>

in cui l'attributo accept permette di filtrare il tipo di file uplodato e maxlength di specificarne la grandezza in byte massima. La servlet che processerà la richiesta sarà UploadFile la quale si aspetta, tramite richiesta POST, un parametro con nome fileUploaded. All'interno della servlet UploadFile inseriamo il seguente codice:

protected void processRequest(HttpServletRequest request, HttpServletResponse response)throws ServletException, IOException{

ServletRequestContext src=null;
src = new ServletRequestContext(request);
if (FileUpload.isMultipartContent(src)){

DiskFileItemFactory dfif=null;
ServletFileUpload fu = null;
String path = "/upload/";
File file = new File(path);
if (!file.exists())

file.mkdirs();

dfif = new DiskFileItemFactory(size,file);
fu = new ServletFileUpload(dfif);
List itemList = null;
try{

itemList = fu.parseRequest(src);

}catch(Exception e){

response.sendError(500,e.getMessage());
return;

}
HashMap<String, FileItem> files
= getFileParameters(itemList);
FileItem fItem = files.get("fileUploaded");
String mime = fItem.getContentType();
int extIndex = mime.length()-3;
String ext = "."+mime.substring(extIndex);
String fileStr = fItem.getFieldName()+ext;
try{

fItem.write(new File(path+fileStr));

}catch(Exception e){

response.sendError(500, e.getMessage());

}
request.setAttribute("msg", "Upload OK");

}
RequestDispatcher rDisp;
ServletContext sc = this.getServletContext();
rDisp = sc.getRequestDispatcher("/info.jsp");
rDisp.forward(request, response);

}
/*
* estrae i FileItem della form e li
* inserisce in una Map in cui le chiavi
* sono i nomi dei parametri
*/
private HashMap<String, FileItem> getFileParameters(List itemList){

HashMap<String, FileItem> ret
= new HashMap<String, FileItem>();
Iterator iter = itemList.iterator();
while (iter.hasNext()) {

FileItem item = (FileItem) iter.next();
if (!item.isFormField()){

String fieldName = item.getFieldName();
ret.put(fieldName, item);

}

}
return ret;

}

Il metodo private HashMap<String, FileItem> getFileParameter(List itemList) in questo caso è poco utile, trattandosi dell'upload di un solo file, ma in genere permette di trattare i parametri di tipo non-FormField (quelli che contengono i file da uploadare) alla stregua dei classici parametri testuali, i quali possono essere inviati al server secondo un ordine non predefinito. I parametri non-FormField vengono inviati al server secondo l'ordine con cui vengono dichiarati nella form per cui una modifica della form potrebbe voler richiedere una modifica nella servlet.
Utilizzando HashMap<String, FileItem> il problema viene aggirato in quanto si fa riferimento ai vari FileItem di tipo non-FormField in base ai nomi e non alla posizione che occupano nella form.

ATTENZIONE: quando l' enctype definito nella form è multipart/form-data anche i tradizionali parametri testuali devono essere prelevati nella servlet usando la tecnica dell' HashMap ( con l'istruzione tradizionale request.getParameter("nomeparametro") il valore restituito è sempre null):

/*
* estrae i parametri testuali della form e li
inserisce in una Map in cui le chiavi sono i nomi dei parametri
*/
private HashMap<String, String> getStringParameters(List itemList){
    HashMap<String, String> ret = new HashMap<String, String>();
    Iterator iter = itemList.iterator();
    while (iter.hasNext()) {
        FileItem item = (FileItem) iter.next();
        if (item.isFormField()){
            String fieldName = item.getFieldName();
            String fieldValue = item.getString();
            ret.put(fieldName, fieldValue);
        }
     }
    return ret;
}

il valore di un parametro sarà prelevato attraverso la seguente istruzione:

....
HashMap<String, String> uploadedParameters = getStringParameters(itemList);
String parameterValue = uploadedParameters.get("parameterName");
...

Alcuni IDE, per esempio Netbeans, permettono di aggiungere in maniera molto semplice un componente per l'uload di file in un applicazione JSF Visual Web (http://www.netbeans.org/kb/60/web/fileupload.html).

Contatore di Sessioni HTTP Attive

2008-10-15T16:27:00.002+02:00

In un applicazione web scritta in Java è possibile contare il numero di sessioni http attive sul server tramite una classe che implementa javax.servlet.http.HttpSessionListener:

package web;
import javax.servlet.http.*;
public class SessionCounter implements HttpSessionListener {

 private static int sessionCounter = 0;
 public void sessionCreated(HttpSessionEvent evt) {

 sessionCounter++;

 }
 public void sessionDestroyed(HttpSessionEvent evt) {

 sessionCounter--;

 }
 public static int getSessionCounter() {

 return sessionCounter;

}

}

In /WEB-INF/web.xml è necessario aggiungere un elemento per definire un application listener specificando il nome della classe appena creata:

<?xml version="1.0" ...>

<web-app>

<listener>

 <listener-class> web.SessionCounter </listener-class>

 </listener>
 ...

</web-app>

Infine è possibile conoscere ed eventualmente visualizzare su una pagina jsp il numero delle sessioni http attive nel seguente modo:

sul server ci sono <%=web.SessionCounter.getSessionCounter()%> sessioni attive

In genere tale conteggio può essere utile per capire quanti utenti sono presenti contemporaneamente su un sito web. Inoltre, aggiungendo una semplice struttura dati(p.e. un Vector aggiornato opportunamente quando vengono invocati i metodi sessionCreated e sessionDestroyed) alla classe SessionCounter, è possibile anche determinare quali utenti sono connessi al server in un dato istante.
Non è superfluo notare che il metodo public void sessionDestroyed(HttpSessionEvent evt) viene invocato sia nel caso in cui la sessione venga invalidata esplicitamente, per esempio attraverso un metodo logout(), sia che la sessione venga invalidata dal container, perchè scade il timeout di sessione attiva.

Sessioni HTTP Uniche

2008-10-15T15:59:00.002+02:00

Vediamo come è possibile estendere il codice del post precedente per implementare facilmente un meccanismo per gestire il problema delle sessioni multiple per utente.
Definiamo una classe che ha la funzione di tenere traccia di tutte le sessioni http attive sul server mediante un HashMap.

package web;
import java.util.HashMap;
import javax.servlet.http.HttpSession;
public class SessionManager {

  private HashMap sessions;

  public boolean exist(String username) {

    if (sessions.containsKey(username)) {

  

      return true;

    

    }

    return false;

  }

  public boolean addSession(HttpSession session) {

    if (sessions.containsKey( session.getAttribute("username"))) {

  

      return false;

    

    }

    sessions.put((String) session.getAttribute("username"), session);

    return true;

  }

  public HttpSession getSession(String username) {

    return (HttpSession) sessions.get(username);

  

  }

  public boolean removeSession(String username) {

    if (!sessions.containsKey(username)) {

  

      return false;

    

    }

    sessions.remove(username);

    return true;

  }

  private static SessionManager sessionManager;

  public static SessionManager getSessionManager() {

    if (sessionManager == null) {

  

      sessionManager = new SessionManager();

    

    }

    return sessionManager;

  }

  public SessionManager() {

    sessions = new HashMap();

  

}

}

Tale classe deve essere definita rispettando il pattern Singleton ed essere utilizzata all'interno di una servlet ogni volta che si vuole creare una nuova sessione, nel seguente modo

if(SessionManager.getInstance.exist(username)) {
SessionManager manager = SessionManager.getInstance();

  logout(manager.getSession(username) );

  manager.removeSession(username);

}

in cui il metodo private void logout( HttpSession session) implementa le azioni necessarie ad invalidare la sessione.
Ovviamente, come descritto nel post precedente, è necessario aggiungere un elemento application listener in /WEB-INF/web.xml:

<?xml version="1.0" ...>
<web-app>

  <listener>

    <listener-class> web.SessionManager </listener-class>

  

  </listener>

  ...

</web-app>

Meccanismo di lock su una coppia <username,password>:
Se si vuole usare il meccanismo illustrato per per fare in modo che per esempio una coppia <username,password> venga usata da un solo cliente alla volta basta riscrivere il codice utilizzato all'interno della servlet come segue:

if(SessionManager.getInstance.exist(username)) {

  response.sendError(403);return;

}