Newsgroup: it.comp.java
Titolo: Problemi con awt con linux

qualcuno ha notizia di errori su server linux con metodi che sfruttano 
le classi awt?
No perchè sotto win va tutto ok, deployando su macchine linux invece no...

posta l'errore che ti da...

 
Lo reputo poco significativo ma:
ype Exception report
message
description The server encountered an internal error () that prevented 
it from fulfilling this request.
exception
javax.servlet.ServletException: Servlet.init() for servlet 
ProcessImageServlet threw exception
	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
	org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
	org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
	org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
	org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
	org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
	java.lang.Thread.run(Thread.java:534)
root cause
java.lang.NoClassDefFoundError
	org.enhydra.jawe.JaWE.getXMLInterface(JaWE.java:47)
	org.enhydra.jawe.JaWEConfig.setValidationStatus(JaWEConfig.java:618)
	org.enhydra.jawe.JaWEConfig.initialize(JaWEConfig.java:256)
	org.enhydra.jawe.JaWEConfig.<init>(JaWEConfig.java:146)
	org.enhydra.jawe.JaWEConfig.getInstance(JaWEConfig.java:113)
	it.edinform.workflow.web.userInteraction.ProcessImageServlet.init(ProcessImageServlet.java:208)
	javax.servlet.GenericServlet.init(GenericServlet.java:211)
	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
	org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
	org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
	org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
	org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
	org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
	java.lang.Thread.run(Thread.java:534)
stesso metodo sotto WIn, nessun problema...

 java.lang.NoClassDefFoundError
Boh... classpath?
Saluti
CarMas

 
E com'è che sotto Windows funge?
Pare che sia un problema noto...

 org.enhydra.jawe.JaWE.getXMLInterface
ti manca il jar che contiene sta roba, oppure, se c'e', non e' leggibile da
tomcat.

marcopar ha scritto:

ma, scusa, secondo te, se mancasse, non darebbe lo stesso problema sotto 
windows?

 windows?
dove lo metti quel jar? in common/libs di tomcat? nel web-inf/lib della tua
webapp?
non e' che magari in windows ce l'hai in common libs e in linux no e nella
webapp non ce l'hai proprio?
quell'errore lo da perche' non trova quella classe. di solito e' perche' il
jar o non c'e' o non hai le permission per leggerlo.
hai detto che sembra essere un problema noto. che significa? ci passi tutte
le informazioni che hai?

marcopar ha scritto:

tutte le lib sono nel war di deploy.
La war che deployo č la stessa, cioč č lo stesso file che fisicamente 
viene deployato ora su una macchina win, ora su una macchina linux (suse 
oss).
cercando di spiegarci perchč succedesse tutto cio', il nostro "esperto" 
linux ha sostenuto che sia un problema legato alle awt che su linux non 
funzionerebbero bene.

> 
pi> Lo reputo poco significativo ma:
pi> ype Exception report
pi> message
pi> description The server encountered an internal error () that
pi> prevented it from fulfilling this request.
Può essere una cazzata, ma X11 è attivo e l'utente con cui gira il
servlet container ha il permesso di scriverci ?
-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico  
\/		    e allevatore di bug da competizione

 
PROBLEMA RISOLTO:
basta far partire tomcat con il parametro
-Djava.awt.headless=true

 -Djava.awt.headless=true
oserei dire: incredibile

marcopar ha scritto:

scusa, perchč?

 scusa, perchč?
l'errore era imho fuorviante... ma forse perche' non conosco il package in
oggetto e l'utilizzo che ne fate

marcopar ha scritto:

il package utilizzato faceva uso della awt, per questo supponevamo fosse 
quello il problema.
L'errore era sicuramente fuorviante, su questo non c'č dubbio.
Ed infatti, per questo mi ci sono rotto la testa 3 gg.

> package in oggetto e l'utilizzo che ne fate
FDSTS> il package utilizzato faceva uso della awt, per questo
FDSTS> supponevamo fosse quello il problema.
FDSTS> L'errore era sicuramente fuorviante, su questo non c'č dubbio.
FDSTS> Ed infatti, per questo mi ci sono rotto la testa 3 gg.
Nessuno di voi ha abitudine all'uso di Unix eh ?? :) :) :) :)
(Tra parentesi: NON avevo detto  una cazzata quando avevo chiesto se X
era  attivo e  se l'utente  con cui  gira l'application  server poteva
accedervi).


 
Assolutamente no, infatti la tua risposta ha acceso interessanti 
dibattiti in azienda.
Ma verificando, i sistemisiti linux hanno verificato che i permessi 
fossero ok

 writes:
FDSTS> Assolutamente no, infatti la tua risposta ha acceso
FDSTS> interessanti dibattiti in azienda.
AWT, vai a  capire per quale motivo, ha bisogno  di poter contattare X
anche se  non apre  nessuna finestra, credo  sia stata  una cappellata
alla  quale  non si  potč  piů porre  rimedio  quando  il problema  si
presentň (credo  anni dopo  la nascita di  Java, quando  comparvero le
servlet).
Vari linguaggi  che si basano su  una VM danno risposte  un po' strane
quando  non riescono  a colloquiare,  evidentemente non  hanno scritto
bene il codice che gestisce i problemi di connessione a X.
FDSTS> Ma verificando, i sistemisiti linux hanno verificato che i
FDSTS> permessi fossero ok
Cosa vale $DISPLAY per l'utente con cui gira il servlet container ?
Se vale stringa  vuota di sicuro non si riesce  a connettere, anche se
avete aperto X11 come una cozza con "xhost +" (comando da non dare mai
nemmeno sotto la minaccia delle armi :) ).


 
considerando che sul serverino di prova la soluzione awt.headless funge 
e sul server vero di deploy invece no, mi sto convincendo di quanto tu 
abbia ragione.

 
Fammi un favore, spiegami come verificarlo da solo il valore di questo 
$DISPLAY, che se aspetto i sistemisti linux ci vogliono sei giorni

> 
FDSTS> Fammi un favore, spiegami come verificarlo da solo il valore di questo
FDSTS> $DISPLAY, che se aspetto i sistemisti linux ci vogliono sei
FDSTS> giorni
Banalmente basterebbe dare il comando 
           echo $DISPLAY
da shell. Solo che bisognerebbe fare  logon con l'utente con cui si fa
girare tomcat.
Più fattibile, almeno  con la debian, lo script  tomcat in /etc/init.d
dovrebbe contenere queste righe:
XSERVER=[host]
...
export DISPLAY=${XSERVER}:0
righe  che garantiscono che  al momento  dell'avvio di  tomcat DISPLAY
contiene l'indirizzo del serve X11 da usare ($DISPLAY indica il valore
della variabile, ${DISPLAY} pure... - man bash :) )
Ah, lo headless mode è solo col dal JDK 1.4, se l'application server di
produzione ha un JDK precedente...
