Newsgroup: it.comp.java
Titolo: Settare le variabili di ambiente

Ciao a tutti,
ho qualche problemino con il settaggio delle variabili di ambiente, o
meglio, non è che ho problemi a settarle, ma sembrano che questi settaggi
non abbiano effetto.
Esempio 1:
Avrei bisogno di mettere nel class path alcuni file jar contenuti in una
cartella (non conosco a priori i nomi del file), e pensavo di farlo
impostando dall'interno del programma la variabile "java.class.path". E
invece non funziona. Se invece setto il classpath da riga di comando con
l'opzione -cp tutto funziona bene. Da notare che la variabile viene
effettivamente impostata perchè se la stampo il valore è giusto.
Esempio 2:
Stessa cosa mi succede con la variabile "java.rmi.server.hostname". Se la
setto da riga di comando con l'opzione -D funziona, se invece la setto con
System.setProperty(...) non ha effetto, pur essendo il valore effettivamente
settato...
Quello che mi chiedo è:   perchè???
Grazie a chi saprà rispondermi.

non abbiano effetto.
Se setti una variabile d'ambiente in Windows 95 e 98 devi riavviare.
Se setti una variabile d'ambiente in Windows NT e Windows 2000 devi
chiudere e riaprire il prompt di DOS.
Se setti una variabile d'ambiente in Linux/UNIX č subito visibile
ovunque.
Interessante, non credi?

[...]
Il punto e' che i setting a linea di comando sono "eseguiti" all'inizializzazione
della JVM; quelli che definisci nel codice tu sono - nel migliore dei casi - 
eseguiti quando viene localizzata e linkata la classe che contiene il main (nel
caso tu li definisca nel suo inizializzatore statico). 
Ma prima di cio', l'ambiente runtime della JVM e' gia' inizializzato, compreso 
ovviamente il ClassLoader. Quindi il ClassLoader non vede la tua java.class.path 
finche' non ha risolto la classe che contiene il main - e se per risolverla
ha bisogno del tuo classpath, ovviamente la cosa non funzionera' mai.
Inoltre nessuno ti dice che un ClassLoader debba rileggere il valore di java.class.path
ogni volta che prova a risolvere una classe piuttosto che solo alla sua 
inizializzazione - anzi, per motivi di efficienza, e' altamente probabile che nessuna 
implementazione lo faccia. Quindi, siccome il ClassLoader e' creato dalla JVM *prima*
che ogni classe esterna sia risolta, anche se cambi il valore nel tuo codice di java.class.path
il ClassLoader di sistema non vedra' questo cambiamento (se proprio vuoi, devi istanziare un
nuovo ClassLoader e usare quello per caricare le tue classi).
Insomma, per certe system properties ha senso un cambiamento a runtime - per altre, no.
Queste ultime sono tutte quelle che devono essere note alla JVM *prima* che l'ambiente 
runtime venga creato.
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun

 Interessante, non credi?
A dire il vero io intendevo settare una variabile dall'interno di
un'applicazione Java con Sistem.setProperty(...), per cui il mio problema
non ha a che vedere con questo.
Comunque non sono del tutto d'accordo con quello che hai scritto.
Sia in Linux che in Windows se setti una variabile d'ambiente, essa è
visibile soltanto nella shell (o nell'istanza di Prompt di Dos) in cui l'hai
settata, ed è immediatamente disponibile. Tutt'al più può essere esportata
ad altre shell "figlie" di quella, ma non è che sia visibile ovunque nel
sistema. Ogni processo ha un suo spazio per le variabili di ambiente.
Caso diverso è se vuoi fare in modo che la variabile sia già settata quando
avvii il sistema, però in questo caso mi sa che devi riavviare anche sotto
linux.... o no? Ma può darsi anche che mi sbaglio...

 >meglio, non è che ho problemi a settarle, ma sembrano che questi

Ciao Crisitiano,
grazie mille per la risposta, mi hai chiarito diversi dubbi, ma tuttora non
sono riuscito a risolvere il problema, anche perchè forse è un po' più
complesso di come l'ho descritto.
In realtà riesco (e riuscivo anche prima) a caricare le classi contenute nei
jar usando un URLClassLoader.
Premetto che si tratta di un'applicazione che usa RMI, ed il problema c'è pr
oprio su uno Stub. Infatti mi viene una ClassCastException (N.B. Non una
ClassNotFound) relativa ad uno stub (contenuto nel jar).
Ma il bello è che se invece lancio l'applicazione mettendo nel classpath il
jar tutto funziona alla perfezione.
L'unica spiegazione che so darmi è che gli stub vengono comunque caricati
dal ClassLoader di sistema anche se la classe base del server remoto è
caricata da un altro ClassLoader (il mio).
C'è una soluzione a questo? L'unica cosa che mi viene in mente è fare un
programmino java che imposta opportunamente il classpath e lancia (usando il
sistema operativo) l'applicazione impostando le opzioni dell'interprete
java.
Si può fare qualcosa di meglio?
In ogni caso, grazie!

remoto è caricata da un altro ClassLoader (il mio).
Per curiosita', stai usando l'RMIClassLoader? (cfr. 
http://java.sun.com/products//jdk/1.2/docs/guide/rmi/spec/rmi-
arch.doc8.html#3933 )
Hai dato un'occhiata a 
http://java.sun.com/j2se/1.3/docs/guide/rmi/codebase.html
 ?


 Hai dato un'occhiata a
http://java.sun.com/j2se/1.3/docs/guide/rmi/codebase.html
 ?
Sì ci ho dato un occhiata, ma il codebase è impostato correttamente (almeno
credo).
Comunque ora ho risolto lanciando una nuova JVM con le variabili di ambiente
settate opportunamente.
In ogni caso, grazie per l'aiuto.