Feeds:
Articoli
Commenti

Archive for the ‘Java’ Category

Per cluster di application servers si intende una serie di istanze del server su cui girano le stesse risorse (le stesse Java web applications). Generalmente istanze diverse girano su Java Virtual Machine differenti e su macchine fisiche separate (sebbene appattenenti alla stessa sottorete) e questo introduce tutta una serie di problematiche peculiari al clustering. Il motivo per cui si ricorre a questa architettura è che in applicazioni di un certo peso la disponibilità del servizio (e le sue prestazioni) devono essere per quanto possibile garantite. In maniera molto semplice (e anche non del tutto precisa), un cluster di tre istanze è sempre in grado di svolgere il suo lavoro (garantire la disponibilità del sito all’utente finale) anche se una o due istanze dovessero incepparsi o crashare. Non solo, se mi accorgo che il sito e molto trafficato, posso sempre aggiungere un’istanza al cluster per ripartire il lavoro (scalabilità). Tutto questo inoltre avviene in maniera trasparente per l’utente finale che, anche se loggato ad un sito, non perderà la sessione, né si accorgerà di nessun cambiamento qualora alcune istanze del cluster dovessero avere dei problemi perché quelle rimaneni si faranno carico del lavoro.

Proseguendo il precedente post, vediamo come installare un architettura cluster su più server Linux fisicamente distinti. Suppongo si siano eseguite le istruzioni per installare Glassfish su un singolo server con supporto cluster abilitato come spiegato nel precedente articolo.

Se avete seguito le istruzioni, l’installazione di Glassfish che ne risulterà, sarà il nostro DAS (Domain Administration Server) vale a dire il nodo centrale di amministrazione delle varie istanze che comporranno il cluster.

È possibile installare una o più istanze all’interno di uno stesso cluster e residenti sulla stessa macchina fisica semplicemente leggendo la documentazione ufficiale e con qualche semplice e intuitiva operazione dalla interfaccia web di amministrazione. Caso più interessante è invece l’installazione di istanze su macchine fisiche separate. Partiamo col dire che le macchine devono appartenere alla stessa sottorete e nessun firewall deve impedire la comunicazione tra le varie istanze del cluster ospitate. Detto questo pensiamo di avere due macchine diciamo:

test1.acme.com

e

test2.acme.com

e supponiamo anche di aver già installato Glassfish con supporto cluster su test1.acme.com così come descritto nel precedente post. Logghiamoci a test1.acme.com con l’utente glassfish e avviamo il server:

asadmin start-domain domain1

Avviato il server, la console di amministrazione sarà disponibile all’indirizzo:

http://test1.acme.com:4848

ora dobbiamo creare un node agent per test1.acme.com

asadmin create-node-agent --host localhost --port 4848 <node-name>>

dove “nodename” è il nome da noi scelto per il nodo (per esempio test1-node). Senza scendere nei dettagli, dobbiamo avere un agent node su ogni singola macchian fisica che entrerà a far parte del cluster. Dalla console di amministrazione possiamo proseguire creando un nuovo cluster e una nuova istanza che assegneremo al cluster (e che avrà come node agent il nodo appena creato e per ora l’unico disponibile). Ora avviamo il node-agent appena creato:

asadmin start-node-agent --syncinstances=true <node-name>

Ora ci dobbiamo loggare sulla seconda macchina che ospiterà una o più istanze del nostro cluster: test2.acme.com. Su questo server dobbiamo installare Glassfish per cui rimando al post precedente alle sezioni “installare il JDK” e “installare ANT”. In questo caso però non abbiamo bisogno di un’installazione completa che creerebbe un secondo DAS ridondante, per cui invece di eseguire il comando

lib/ant/bin/ant -f setup-cluster.xml

useremo questo di seguito:

lib/ant/bin/ant -f setup-cluster.xml create-node-agent --nodeagent <node-agent-name> -Ddas.host="test1.acme.com"

Dove “host” è l’host su cui è installato il DAS (nel nostro caso test1.acme.com) e <node-agent-name> è il nome del nuovo nodo che stiamo per creare (per esempio test2-node). Ci deve essere un node agent per ogni macchina fisica distinta destinata ad ospitare istanze del cluster e ovviamente il nome del nodo deve essere unico entro un cluster.
Avviamo il nuovo node agent creato su test2:

asadmin start-node-agent --syncinstances=true <node-agent-name>

Logghiamoci alla admin console (o facciamo un refresh se siamo già loggati) e nella sezione dedicata ai nodi dovremmo poter essere in grado di vedere il nuovo nodo appena creato su test2.acme.com. Sempre attraverso l’interfaccia web di amministrazione possiamo creare nuove istanze appartenenti al cluster e assegnarle il nodo su test2. Questo vuol dire che l’istanza verrà creata e girerà su test2.acme.com.
Le istanze del cluster girano su porte particolari. Se, per esempio, creiamo due istanze su test2.acme.com e una su test1.acme.com avremo le varie istanze del server in ascolto su queste porte:

A questo punto di solito si prosegue creando un load balancer e integrando Glassfish con un web server tipo Apache. Avremo quindi un unico URL con cui invocare la nostra applicazione java e dietro le quinte il load balancer deciderà concretamente (e in maniera trasparente per l’utente) a quale istanza del cluster indirizzare la richiesta.

Un ultima nota dedicata più agli sviluppatori Java. Le librerie (file .jar) che dovrebbero essere condivise tra le farie applicazioni java deployate su uno stesso cluster (per esempio un driver jdbc per un database) dovrebbero essere piazzate qui:

<glassfish-home>/domains/domain1/config/<cluster-name>-config/lib

La documentazione completa sul clustering su Glassfish (e argomenti correlati) è disponibile qui:


http://glassfish.dev.java.net/nonav/javaee5/docs/SJSASEEHAAG.pdf

Read Full Post »

Glassfish e un application server che stà riscuotendo una crescente popolarità ed è giunto ad una fase di maturità tale da farne un ottimo candidato per applicazioni professionali in campo aziendale. Glassfish è free ed open source ed è sfornato dalla Sun (casa madre di Java). La versione 2 è un container pienamente conforme alle specifiche JEE 5, questo significa in altre parole che potete deployare EJB (anche la versione 3.0), JMS, ecc. e lo distingue da servlet container come Tomcat o Jetty. Un servlet container, anche conforme alle specifice Java, come suggerisce il nome, può essere di default solo utilizzato per deployare Servlet, JSP, ecc. ma non EJB appunto perché Tomcat non è e non è pensato per essere, un EJB container. Come corollario, mentre su Glassfish potete installare tutte le applicazioni Java che girano su Tomcat, non vale il viceversa: applicazioni Java che fanno uso di tecnologie quali EJB o JMS non possono essere deployate su Tomcat. Glassfish appartiene in sostanza alla stessa famiglia di JBoss e Geronimo (progetto Apache), con cui condivide la caratteristica di essere free e open source, ma anche, sul lato commerciale, di Weblogic (Bea) e WebSphere (IBM).
Ho installato Glassfish V2 sotto un server Linux RedHat e sul mio portatile su cui gira Ubuntu 7.10. La procedura è simile ma c’è qualche piccola differenza principalmente dovuta al fatto che mentre è normale disporre di un ambinete grafico su un sistema Linux per utente finale (caso di Ubuntu installato sul portatile) questo non è normalmente il caso su un server Linux su cui spesso ci si connette da remoto e si opera attraverso una shell.
In questa prima quida prenderò in considerazione l’installazione su un server Linux (nella fattispece RedHat) dove si possono presentare anche esigenze di clustering (argomento a mio avviso non del tutto chiaro nella documentazione ufficiale). L’installazione di Glassfish sul Ubuntu 7.10 sarà lasciata ad un prossimo post.

Per installare e configurare Glassfish V2 abbiamo bisogno di un JDK5 o un JDK6 presente sul server. Accertatevi di aver installato un JDK e non un semplice JRE (per la differenza vedi qui). Potete sempre verificare la versione di Java eventualmente già installata sul server con questo comando:

java –version

Ora creiamo un nuovo user (diciamo “glassfish”):

adduser glassfish

Se sul vostro server è già installato un JDK (e se combacia con una delle due versioni di cui abbiamo bisogno per Glassfish) allora potete saltare la prossima sezione.

Come installare il JDK

Fate il download del JDK (1.6) da qui (ovviamente per Linux):

http://java.sun.com/javase/downloads/index.jsp

o del JDK (1.5) da qui

http://java.sun.com/javase/downloads/index_jdk5.jsp

copiate il file scaricato (un .bin) in una directory di vostra scelta, diciamo

/opt

spostatevi nella directory

cd /opt

ed eseguite il file per installare il JDK

./jdk-1_5_0_14-linux-i586.bin

Ora dobbiamo settare la variabile d’ambiente JAVA_HOME e modificare la variabile d’ambiente PATH per includere gli eseguibili Java che abbiamo installato con il JDK. Se vogliamo rendere disponibili questi settaggi per tutti gli utenti del sistema dovremo editare il file

/etc/profile

Se invece vogliamo rendere disponibili questi nuovi settaggi solo per l’utente glassfish dovremmo solo editare il file:

/home/glassfish/.bash_profile

in entrambi i casi le linee extra che dobbiamo aggiungere al file sono le seguenti:

JAVA_HOME=/opt/jdk1.5.0_14
PATH=$JAVA_HOME/bin:$PATH
export PATH
export JAVA_HOME

Io consiglierei di modificare i settaggi per il singolo user glassfish che sembra essere un’approccio meno intrusivo e più prudente specie su un server su cui potrebbero girare altri applicativi di cui non siamo a conoscenza. Se decidete per queasta strategia loggatevi come glassfish e procedete con questo utente da ora in poi.

Installare ANT

ANT è un prerequisito per l’installazione di Glassfish. Lo script d’installazione controllera il filesystem alla ricerca del file:

/etc/ant.conf

Che nel vostro server sarà presente solo se ci dovesse essere una versione di ANT già installata. Il file in questione, se ci date una sbirciata dentro, non fa altro che settare la fariabile di ambiente ANT_HOME (per esempio qualcosa come ANT_HOME=/usr/share/ant) che Glassfish userà durante l’installazione. Tenete presente che Glassfish richiede una versione di ANT uguale o superiore alla 6.5. Se ANT non è già installato sul vostro sistema, potete scaricarlo da qua:

http://ant.apache.org/bindownload.cgi

Scompattate il file (per esempio in /opt) e la directory che otterrete sarà la vostra ANT_HOME. Non vi rimane che creare un file /etc/ant.conf che punti alla vostra ANT_HOME. Se un’installazione di ANT è già presente sul vostro sistema ma volete usare un’altra versione di ANT senza interferire con le applicazione già installate che potrebbero usare la versione installata, potete creare il vostro file ant.conf che punti alla vostra ANT_HOME e poi editare il file

/lib/ant/bin/ant

per farlo puntare al vostro ant.conf. Il file lib/ant/bin/ant non esiste ancora a questo punto perché dobbiamo ancora installare Glassfish, cosa che faremo nella prossima sezione. Il file ant.conf, in ogni caso, assomigliarà a qualcosa tipo:

# /etc/ant.conf
# Options for classic-ant
# ANT_HOME is the directory in which the jarfiles that are required by
# classic-ant are located.
ANT_HOME=/opt/ant

Installare Glassfish

Potete scaricare una copia di Glassfish (che si presente come un file .jar) da qua:

https://glassfish.dev.java.net/downloads/v2ur1-b09d.html

Una volta scaricato il file copiatelo nella directory

/opt

Spostatevi dentro questa directory:

cd /opt

ed eseguite il seguente comando:

java -Xmx256m -jar filename.jar

dove “filename” è il nome del file che avete scaricato (per esempio glassfish-installer-v2ur1-b09d-linux.jar). Spostatevi nella directory creata:

cd glassfish

e date i permessi di esecuzione agli script ANT inclusi in Glassfish:

chmod -R +x lib/ant/bin

Ora dobbiamo decidere se vogliamo installare un singolo server o un server con supporto per il clustering. Nel primo caso eseguiamo:

lib/ant/bin/ant -f setup.xml

nel secondo invece:

lib/ant/bin/ant -f setup-cluster.xml

Tenete presente che, se scegliete la prima via, è sempre possibile aggiungere il supporto cluster dalla console di amministrazione in modo semplice ed intuitivo. Spostatevi ora nella directory bin ed eseguite:

./asadmin start-domain domain1

Per far partire Glassfish mentre per arrestarlo potete usare:

./asadmin stop-domain domain1

Ora dovreste essere in grado di amministrare Glassfish da remoto attraverso una comoda ed elegante interfaccia web semplicemente collegandovi al seguente indirizzo:

http://host-name:4848

con username “admin” e password “adminadmin”. Trovate anche una nutrita documentazione (in inglese) sul sito a questo indirizzo:

https://glassfish.dev.java.net/javaee5/docs/DocsIndex.html

Read Full Post »

tomcat

Tomcat è un servlet container o in parole semplici è un server su cui è possibile far girare Servlet e JSP che sono alcune delle tecnologie Java (J2EE) più utilizzate nella programmazione web. Alcune cose utili da sapere prima di procedere con l’installazione:

  • Tomcat è free, open source ed è scritto in Java per cui è anche multipiattaforma
  • Essendo scritto in Java dovete avere Java installato. Vedere qui per come fare
  • tecnologie come EJB, JMS, ecc. richiedono per l’appunto un EJB container: vale a dire non potete far girare EJB su Tomcat.
  • Tomcat può anche servire normali pagine statiche HTML ma a questo scopo e per usi professionali si tende ad utilizzare Apache. In ambito aziendale Tomcat trova spesso il suo impiego “dietro” un server Apache che si occupa di servire i contenuti statici e demanda a Tomcat il compito di servire pagine dinamiche.

Su Ubuntu Tomcat è disponibile nei repository ufficiali nella versione 5.5 ed è facilmente inspallabile attraverso Synaptic (System -> Administration -> Synaptic Manager) o se preferite da terminale:

sudo apt-get install tomcat5

Tuttavia la versione nel repository non è la più aggiornata. Sul sito è disponibile la versione 6 che al di là degli ovvi bug fixing supporta una versione più aggiornata della specifiche Servlet e JSP di Sun.

Brevemente:

  • Tomcat 6.0.x supporta le specifice Servlet 2.5 e le specifiche JSP 2.1
  • Tomcat 5.5.x supporta le specifice Servlet 2.4 e le specifiche JSP 2.0
  • Tomcat 4.1.x supporta le specifice Servlet 2.3 e le specifiche JSP 1.2
  • Tomcat 3.3.x supporta le specifice Servlet 2.2 e le specifiche JSP 1.1

Ne consegue che se volete installare la versione più aggiornata o una datata, dovrete installare Tomcat a mano (il che è veramente semplice)

La seguente procedura è testata su Tomcat 6.0.14 e Ubuntu 7.04 con java settato come in uno dei miei precedenti post ma sarei veramente sorpreso se non si adattasse alle altre principali distribuzioni Linux e alle altre versioni di Tomcat. Iniziamo con lo scaricare Tomcat da qua per la versione 6 oppure scegliete un’altra versione da qua. Selezionate il file tar.gz sotto “Core” sotto “Binary Distributions” a fate il download.
Scaricato il file spostatelo sotto /opt o in un’altra directory di vostra scelta e scompattatelo. Vi ritroverete con una directory dal probabile nome di apache-tomcat-6.0.14 e potete anche rimuovere il file .tar.gz. Di fatto l’installazione è terminata. Per usare il server appena installato vi potrebbero far comodo le seguenti basilari informazioni.

  • Avvio e shutdown del server: potete avviare e stoppare tomcat attraverso due script che trovate nella directory bin. Da terminale eseguite:

    /opt/apache-tomcat-6.0.14/bin/startup.sh (per avviare il server)

    /opt/apache-tomcat-6.0.14/bin/shutdown.sh (per stoppare il server)

    Ora dipende dai vostri gusti ma se volete semplificarvi la vita ed evitare ogni volta di digitare tutta la stringa potete aggiungere al $PATH anche la directory di Tomcat (vedi env_vars nel post su Java) o creare un link e metterlo in una delle directory già nel $PATH (per vederlo: echo $PATH) o creare un launcher sulla barra delle applicazioni, ecc.

  • Log del server: per qualsiasi problema il primo posto dove guardare è il log del sistema che si troverà in questo esempio in:

    /opt/apache-tomcat-6.0.14/logs/catalina.out

    Se è molto lungo potete utilizzare da terminale:

    tail -500 /opt/apache-tomcat-6.0.14/logs/catalina.out

    che stamperà a video solo le ultime 500 righe del file.

  • Configurazione: non dovreste avere bisogno di cambiare niente dei settaggi di default, almeno per una configurazione standard. In ogni caso il comportamento del server è regolato attraverso una serie di file presenti sotto la cartella /opt/apache-tomcat-6.0.14/conf e principalmente il file server.xml dove tra le altre cose è definita la porta di default su cui il server si pone in ascolto (8080) e altre opzioni avanzate (cluster, connectors, ecc.)
  • Amministrazione se il server è stato avviato senza intoppi (ed è stato installato in locale come si suppone in questo esempio) potete inserire in un browser in seguente indirizzo:

    http://127.0.0.1:8080/

    e vi apparirà la schermata di amministrazione del server. Le finzioni sotto administration richiedono il login quindi prima dovete creare uno user. Aprite il file/opt/apache-tomcat-6.0.14/conf/tomcat-users.xml e aggiungete le seguenti due righe:


    <role rolename="manager"/>
    <user username="manager" password="password" roles="manager"/>

    in modo che il file finale assomigli a qualcosa di questo tipo:


    <?xml version='1.0' encoding='utf-8'?>
    <tomcat-users>
    .
    .
    <role rolename="manager"/>
    <user username="manager" password="password" roles="manager"/>
    </tomcat-users>

    Riavviate il server e ora dovreste essere capaci di accedere a “Tomcat Manager” con le credenziali appena create. Da questa sezione di amministrazione potrete poi controllare le java web applications attive sul sistema, deployarle, aggiungerne di nuove attraverso l’upload di un file .war e tante altre belle cose ancora.

  • Monitoraggio: per monitorare il server potete sempre usare i seguenti due comandi da terminale:

    ps -ef | grep tomcat

    per controllare se Tomcat è tra i processi attivi sul vostro pc oppure:

    sudo nmap -sS 127.0.0.1

    per controllare le porte aperte sul vostro computer e il particolare quella su cui Tomcat è in ascolto. Tenete presente che nmap potrebbe non essere installato sul vostro sistema.
    Questi basilari comandi vi aiutano anche in un primo troubleshooting. Se per esempio il server non parte e controllando catalina log vedete qualcosa del tipo:


    LifecycleException: service.getName(): "Catalina"; Protocol handler start failed: java.net.BindException: Address already in use:8080

    vuol dire che la porta 8080 è già occupata da un altro processo, forse una precedente istanza di tomcat che non è stata propriamente stoppata (ve lo potrebbe dire ps -ef) oppure c’è un qualche altro programma in ascolto su quella porta (ve lo potrebbe dire nmap).

Read Full Post »

Eclipse è un IDE (Integrated Development Environment) principalmente per la programmazione in Java. Un IDE è un ambiente di sviluppo completo per la programmazione in un certo linguaggio e Eclipse si è affermato in ambito Java ormai da tempo anche in contesti aziendali in cui è stato preferito ad altri più o meno costosi IDE (per esempio JBuilder) principalmente per il fatto di essere open source, gratis e per avere molte delle caratteristiche che ci si aspetterebbe da un IDE professionale. Eclipse è scritto in Java e quindi dovete installare una JVM per faro girare: potete dare un’occhiata al precedente post per vedere come fare. Ultima cosa da notare: con Eclipse 3.3 (al momento in cui scrivo la più recente) viene offerto un package specifico per la programmazione C e C++ ed è inoltre sempre possibile utilizzare questo IDE per la programmazione in PHP con l’installazione di un plug-in aggiuntivo.
Se usate Ubuntu (o una derivata Debian), Eclipse è nel repository e quindi può essere installato semplicemente attraverso Synaptic (System -> Administration -> Synaptic Manager) oppure da terminale e riga di comando:

sudo apt-get install eclipse

La versione nel repository però è un pò datata (3.2) mentre quella disponibile sul sito (http://www.eclipse.org/) è più recente (3.3) e contiene molte novità e miglioramenti. Chi utilizza Eclipse di solito è un utente professionale e la versione potrebbe essere un parametro da tenere in considerazione. C’è da dire che Eclipse è espandibile e integrabile con diversi plug-in sviluppati dalla comunità e di solito le versioni più datate offrono maggior supporto e maggior scelta di questi componenti. Fatto un bilancio complessivo ho optato per la versione più recente (3.3) scaricabile dal sito (http://www.eclipse.org/) anche perché offre differenti scelte tra cui un package apposito per lo sviluppo con tecnologie java JEE.
Se volete seguire questa strada allora occorre scaricare l’occorrente da qui. Sono presenti diverse opzioni quindi dovete scegliere quella che si addice di più alle vostre esigenze. Spendo due parole in più su questi tre pacchetti:

  • Eclipse IDE for Java EE Developers: questa è la scelta ottimale se programmate con tecnologie Java EE come Servlet, EJB, JSP, JMS ecc. di solito utilizzate in ambito web per progetti enterprise di una certa importanza
  • Eclipse IDE for Java Developers: questo se vogliamo è il pacchetto standard per creare applicazioni Java. Un IDE aiuta solamente il programmatore per cui anche con questo pacchetto potete creare applicazioni Java EE. Semplicemente alcuni tools e utility non sono fornite
  • Eclipse IDE for C/C++ Developers: come dice il nome è per chi si occupa di programmazione in C e C++

eclipse

Tutti i pacchetti richiedono una versione del jdk uguale o superiore alla 1.5. Una volta scelto il pacchetto, fate il download. Nel mio caso ho scelto Eclipse IDE for Java EE Developers (ma la procedura è identica per gli altri pacchetti e in teoria si dovrebbe adattare a tutte le distribuzioni Linux). Fatto il downoad mi ritrovo con un file

eclipse-jee-europa-linux-gtk.tar.gz

che decido di installare nella directory

/opt (dopotutto è un package opzionale)

Userò la procedura da terminale ma ovviamente se preferite potete eseguire i semplici passi che seguono da interfaccia grafica. Copiamo il file in /opt:

cp eclipse-jee-europa-linux-gtk.tar.gz /opt

Potreste aver bisogno di utilizzare sudo o avere i privilegi di root (dipende dai permessi sulla directory /opt nel vostro sistema). Spostatevi in /opt:

cd /opt

e scompattate il file:

tar -zxvf eclipse-jee-europa-linux-gtk.tar.gz

e ora possiamo eseguire Eclipse semplicemente con il comando da terminale:

/opt/eclipse/eclipse

Ovviamente possiamo creare un launcher nella barra delle applicazioni, specificare /opt/eclipse/eclipse come comando e usare l’icona /opt/eclipse/icon.xpm

Segnalo anche due altri interessanti post sull’argomento:

http://www.paoloferretti.it/blog/2007/05/25/installare-eclipse-su-ubuntu-704-feisty-fawn/

http://orter.wordpress.com/2007/06/11/installare-eclipse-su-ubuntu-704-versione-64-bit/

Read Full Post »

Chi lavora con Java si sarà spesso imbattuto nella famigerata java.lang.ClassNotFoundException. Dopo le imprecazione del momento sorge spesso la necessita di scoprire in quale tra le decine di file jar nel classpath si annida questa benedetta classe. Ovviamente questo è solo un esempio di uno scenario in cui disporre di uno strumento in grado di ricercare ricorsivamente per nome una classe in svariati archivi jar può fare la differenza. Per chi lavora in ambiente Linux ho trovato una risposta qui e la ripropongo tradotta e più dettagliata nei passaggi.
Per prima cosa dobbiamo creare uno script bash che potete chiamare come vi pare (io l’ho chiamato findclass) e che va messo nel path (io ho scelto /usr/local/bin).
Da terminale spostiamoci in /usr/local/bin:

sudo touch findclass

sudo gedit findclass (o qualsiasi altro editor come vi va bene)

incollate dentro il file findclass le seguenti righe:

#!/bin/bash
# This is a program for finding a Class in a ton of jars

find . -name "*.jar" | xargs -i unzip -l {} | grep -E "^Archive:|$1" | less

Salvate e chiudete. Ora spostatevi nella directory in cui avete tutti i jar e provate da terminale a dare il comando appena creato. L’optput dovrebbe essere qualcosa tipo:

> findclass Enclosed
Archive: ./aspectj-1.5.3.jar
Archive: ./aspectjweaver.jar
Archive: ./junit.jar
651 27-03-07 14:22 org/junit/runners/Enclosed.class

Vale a dire che sono stati passati in rassegna tre archivi jar e la classe Enclosed è stata trovata in junit.jar. Il programma less, per uscire basta premere “q”.
Se per qualche ragione non vi trova il comando che avete creato (findclass) stampate il path a terminale:

echo $PATH

e controllate che il file creato sia all’interno di una delle directory riportate nel path.

Read Full Post »

Ubuntu include già una sua implementazione della java virtual machine (gcj) ma per alcuni scopi questa non è abbastanza o non è soddisfaciente (per esempio Eclipse 3.2 si inchioda). Se non avete mai avuto problemi con applicativi Java potreste smettere di leggere quanto segue ma se per qualche ragione lavorate o smanettate con Java o usate applicativi Java piuttosto “esigenti” (Eclipse, Tomcat, ecc.) sarebbe meglio passare alla JVM della Sun (o anche IBM).
Prima di tutto bisogna fare una distinzione di base tra il JRE e il JDK:

  • Entrambi contengono la JVM (Java Virtual Machine)
  • il JRE (Java Runtime Environment) contiene diverse librerie e consente di far girare tutti gli applicativi Java
  • il JDK (Java Development Kit) comprende il JRE più tutta una serie di strumenti utili per lo sviluppo con Java

La via più veloce consiste nello scaricare il JDK o JRE tramite Synaptic. Al momento in cui scrivo sono disponibili la versione 5 (Java SE 1.5) e 6 (Java SE 1.6). Se per qualche ragione si vuole installare la versione 4 (Java SE 1.4) non rimane che fare il download dal sito della Sun. Programmatori o smanettoni potrebbero anche volere l’ultimo build disponibile per una data versione e anche in questo caso non rimane che affidarsi al sito della Sun in quanto la versione nel repository non è quasi mai aggiornata all’ultima disponibile. Potete scaricare l’ultima versione (1.6) da qui, oppure quelle precedenti (1.5, 1.4, 1.3) da qui.
Lavorando con più versioni Java, preferisco installare da solo i vari JDK scaricati da Sun senza dipendere in alcun modo dal repository ma se non avete particolari esigenze non vale la pena complicarsi la vita.
Nell’ipotesi in cui vogliate scaricare, supponiamo, il JDK 6 (1.6), dovete selezionare il file Linux self-extracting file (procedura praticamente identica per il JRE e per le versioni vecchie). Spostate il file scaricato nella directory in cui volete installare Java (per esempio /opt), date i permessi di esecuzione al file:

chmod + x jdk-6u2-linux-i586.bin

potreste anche aver bisogno dei privilegi del superuser, dipende in quale directory avete spostato il file. In quest’ultimo caso ovviamente:

sudo chmod + x jdk-6u2-linux-i586.bin

poi eseguite il file:

./jdk-6u2-linux-i586.bin

Anche in questo caso probabilmente avrete bisogno di usare sudo.
La directory che otterrete dopo l’installazione jdk1.6.0_02 sarà la vostra JAVA_HOME: una variabile di ambiente che vedremo come settare tra poco.
Il problema in cui sono incappato subito dopo l’installazione è che Ubuntu (almeno le versioni 5.10, 6.06 e 6.10) dimostra una certa riluttanza a far girare gli applicativi Java con la JVM di Sun appena installata preferendovi la sua di default (che come detto può causare alcuni problemucci). Il problema consiste quindi nel far capire a Ubuntu quale JVM utilizzare. Disinstallare gcj non sembra risolvere il problema per cui ho optato per una soluzione diversa.
Creare un file in

/etc/X11/Xsession.d/

chiamato

55load-my-env-vars

Editare il file e scrivere il seguante contenuto

. /opt/env_vars

creare un altro file nella directory

/opt

chiamato

env_vars

aprite il file appena creato e scriveteci dentro le seguenti righe


# Sourced by:
# /etc/bash.bashrc (for interactive non-login shells)
# /etc/X11/Xsession.d/55load-my-env-vars (for Xsessions)
PATH=/opt/java/bin:$PATH
export JAVA_HOME=/opt/java

Ovviamente il path deve puntare alla directory in cui avete intallato la JMV (nel mio caso appunto /opt/java). Aggiungete la seguente riga di testo al file .bashrc nella vostra home directory:

. /opt/env_vars

A questo punto al prossimo reboot il settaggio della java virtual machine dovrebbe essere corretto. Concludo con un paio di note: questa procedura è utile nel caso si avvii il sistema Linux direttamente in modalità grafica (penso sia la norma ormai). Se avviate il siste non in modalità, allora potrebbe essere sufficiente semplicemente definire il PATH ed esportare la JAVA_HOME editando solo il file .bashrc nella vostra home directory. Potete sempre verificare la versione della JVM installata con un

java -version

da terminale. Per controllare quale versione della JVM i vostri programmi Java utilizzano, dovrebbe essere sufficiente un

ps -ef | grep nome-programma

da terminale.

Read Full Post »