lunedì 29 dicembre 2008

Three state logic

In un applicativo che sto sviluppando mi è capitato di dover gestire una logica a tre stati:

- Vero

- Falso

- Indifferente

Nell'object model è abbastanza agevole svilupparlo con un attributo di tipo Boolean che ammette i valori: true, false, null. Ma cosa succede nell'interfaccia utente?
Non è possibile usare un check-box, perchè ammette soltanto due valori, sembra più adatto un listbox!
Per poter usare agevolmente il listbox è però più opportuno avere un'enumerazione invece del Boolean. Si possono però prendere due piccioni con una sola fava creando l'enumerazione come segue:


public enum TreStati {
VERO(Boolean.TRUE),
FALSO(Boolean.FALSE),
INDIFFERENTE(null);

private Boolean val;

private TreStati(Boolean val) {
this.val = val;
}

public Boolean getVal() {
return val;
}

public static TreStati fromBoolean(Boolean val) {
if (val == null) {
return INDIFFERENTE;
} else if (val) {
return VERO;
} else {
return FALSO;
}
}
}


A questo punto nella classe dell'object model potete usarlo così:


private Boolean attr;

public TreStati getAttr() {
return TreStati.fromBoolean(attr);
}

public void setAttr(TreStati attr) {
this.attr = attr.getVal();
}


Ovviamente, se necessario, potete anche aggiungere degli accessor method che manipolano direttamente l'attributo Boolean

mercoledì 13 agosto 2008

JBoss

Finora ho fatto il deploy degli applicativi di Matica su una installazione di Tomcat 6.0, ma recentemente cominciano a sorgere delle necessità che con Tomcat non sono proprio banali da risolvere, come, ad esempio, quella di utilizzare delle code JMS. In questo caso avrei dovuto installare un gestore JMS esterno, configurarlo ecc... Allora mi sono detto: perchè non proviamo con JBoss che invece questi servizi ce li ha già?
Non avevo mai usato JBoss perciò ho cominciato a provare e ho avuto qualche problemino già in fase di startup. Niente di insormontabile, ovviamente. Ecco cosa è successo.

Innanzitutto ho provato a seguire il manuale:
- ho scompattato il pacchetto di JBoss 4.2.3GA in /opt/jboss
- ho impostato nel mio .bashrc le variabili JAVA_HOME e JBOSS_HOME rispettivamente alle directory che contengono l'installazione della JVM e di JBoss
- ho lanciato lo script di startup con /opt/jboss/bin/run.sh

E lo script è andato in errore! Forse il mio utente non ha abbastanza privilegi, proviamo con sudo:

sudo -E /opt/jboss/bin/run.sh

Stavolta funziona! Ho dovuto usare l'opzione -E di sudo per fare in modo che le variabili d'ambiente che avevo impostato nel mio .bashrc fossero mantenute anche nella shell che lancia JBoss.

Ho provato a connettermi alla pagina di benvenuto di JBoss prima da un browser sulla stessa macchina, poi da uno su un'altra macchina (virtuale, poichè al momento ho un solo PC). La cosa strana è che funziona solamente da localhost. Se provo ad usare l'indirizzo della macchina, sia da loacle che da remoto, JBoss non risponde.

Ho cercato un po' in rete e ho scoperto che dalla 4.2 in poi JBoss si mette in ascolto solamente sull'indirizzo 127.0.0.1 (per gli amici "localhost") mentre per metterlo in ascolto su un altro indirizzo occorre usare il parametro -b , ad esempio:

sudo -E /opt/jboss/bin/run.sh -b 192.168.0.165

Così però non funziona più se lo chiamo da localhost. Se si vuole farlo funzionare in ogni caso basta usare -b 0.0.0.0

Nel cercare questa informazione ho scoperto anche la pagina del wiki di JBoss dove sono elencate le opzioni dello script di startup:

http://wiki.jboss.org/wiki/JBossRunParameters

e che nella stessa directory dello script c'è un file, chiamato run.conf, che permette, sotto unix/linux/ecc. , di impostare le variabili d'ambiente.
Perciò ho spostato la definizione della JAVA_HOME dal mio .bashrc a run.conf e ora posso lanciare il tutto senza l'opzione -E di sudo. Riassumendo:

sudo /opt/jboss/bin/run.sh -b 0.0.0.0

Ora sarebbe carino riuscire a lanciarlo come servizio! Ma questa è un'altra storia

domenica 6 luglio 2008

Restart Apache

In Matica (http://www.maticasrl.it) stiamo utilizzando una macchina Ubuntu Linux come application server. Ho creato diverse instanze di tomcat su questa macchina in modo da poterne fare il restart senza influenzarsi a vicenda.
A questo punto ho utilizzato Apache HTTP come proxy di fronte a queste istanze e mi sono posto il problema di come farne il restart ogni volta che cambiavo il file di configurazione. Inizialmente ho scoperto che dalla finestra che elenca i servizi si poteva fare in questo modo:

- togliere il segno di spunta accanto al servizio
- chiudere e riaprire la finestra dei servizi
- rimettere il segno di spunta

Un po' troppo macchinoso! Anche perchè dovevo farlo proprio sulla consolle della macchina. Io volevo qualcosa da linea di comando in modo che lo potevo usare collegandomi con putty
Tempo fa avevo usato xinet.d per avviare CVS, come consigliato sul manuale, ma non ho trovato nessuna configurazione di apache sotto /etc/xinet.d
Ho cercato un po' in giro ma alla fine ho scoperto che nella cartella /etc/init.d ci sono le shell di startup dei servizi. Non ne so ancora molto ma per fare il restart di apache è bastato il seguente comando

/etc/init.d/apache2 restart

venerdì 4 gennaio 2008

Trasloco

No, non ho cambiato casa, ho soltanto cambiato PC.
Stavo sviluppando la mia nuova applicazione con ZK sul notebook aziendale, ma dovendo cambiare azienda l'ho dovuto riconsegnare. Di conseguenza ho dovuto trasferire tutto sul PC fisso che ho a casa. Niente di problematico se non fosse che su quel PC c'è Linux. Ora sta funzionando tutto ma poichè ci ho messo un po' voglio raccontare la mia esperienza.

Fortunatamente stavo salvando tutto ciò che sviluppavo su un repository Subversion che tenevo in locale sul mio notebook. Dunque la prima cosa che ho fatto è stato un back-up di questo repository. Grazie all'ottimo libro "Pragmatic Version Control using Subversion" è stato facilissimo. Linea di comando e:

svadmin dump nomedir > dumpfile

dove nomedir è la directory contenente il repository e dumpfile è il nome del file che conterrà il back-up.

Poichè sono previdente, quando avevo installato Linux (Ubuntu 7) sul PC avevo scelto di installare anche Subversion, dunque ricostruire il repository è stata una bazzecola. Sempre seguendo "Pragmatic ...", ho aperto una shell e:

svnadmin create nomedir
svnadmin load nomedir < dumpfile

dove nomedir, come prima, è il nome della directory che conterrà il repository e dumpfile è il file di back-up.

Un po' di problemi me li ha dati, invece, Eclipse.
L'installazione dell'ambiente Eclipse in se non è stata complicata, ma i plugin...
Infatti ho la malsana abitudine di riempire Eclipse di numerosi plugin, dunque dovevo ripristinare la situazione sul nuovo PC.
Inizialmente pensavo di procedere manualmente. Sono andato sul notebook, ho aperto Eclipse, Help/Software Updates/Find and install... e poi, scelto "Search for new features ...", è comparso l'elenco dei siti da cui ho scaricato i vari plugin. Ho cominciato a copiarlo su un foglio di carta per poi riportarlo sul nuovo e scaricare così tutti i plugin ma stavo per arrendermi!
Finchè non ho visto il pulsante "Export sites" !
Con questa funzione Eclipse copia tutto su un file xml che poi può essere ricaricato tramite il pulsante gemello "Import sites". Fantastico!
E così anche l'installazione dei vari plugin è stata una passeggiata ... fino a Subversive.

Subversive è un plugin di Eclipse che permette di sincronizzare i progetti con un repository Subversion. Tra tutti era proprio il plugin fondamentale!
Ma, una volta installato, provo ad aprire la pagina di configurazione del plugin all'interno di Window/Preferences e... noto un bruttissimo errore. Sembra che il plugin non riesca a trovare la libreria JavaHL.

E adesso cos'è JavaHL?!

Dopo qualche ricerca su Internet l'ho capito. Per poter accedere ad un qualsiasi repository di un software di configuration management, un'applicazione ha bisogno di una qualche libreria. Al contrario di altri (es. CVS) Subversion possiede un proprio set di librerie che permettono di accedere ad un repository da vari linguaggi di programmazione. JavaHL è appunto la libreria standard per poter accedere ad un repository CVS da un'applicazione Java.

Ma perchè non la trova?

Presto detto! Mentre la distribuzione Windows di Subversion include JavaHL già bella e pronta, la distribuzione Linux di Subversion no (immagino per i soliti problemi di licenza, mah?!). Dunque bisognerebbe scaricarsi i sorgenti di Subversion e ricompilarli dicendogli di includere anche JavaHL.

Fortunatamente il plugin Subversive permette di accedere ai repository anche utilizzando un'altra libreria: SVNKit. Questa viene distribuita direttamente con il plugin perciò si può utilizzare tranquillamente anche se, rispetto a JavaHL, ha qualche limitazione.
La principale limitazione è che non è possibile utilizzare repository locali, quelli a cui si accede tramite un URL del tipo file://.... , ma solamente a repository svn server, quelli a cui si accede tramite un URL tipo svn://....
Ma anche qui non è stato difficile, sempre grazie a "Pragmatic...".
Basta infatti avviare svn server facendolo puntare alla directory contenente il nostro repository con la seguente istruzione:

svnserve --daemon --root nomedir

A questo punto basta far puntare Subversive a svn://localhost per accedere al repository locale.

Magari quando avrò un po' di tempo proverò anche a compilare JavaHL. Vi prometto un post sull'argomento!

A presto