Newsgroup: it.comp.java
Titolo: Exception running Jetty

Salve a tutti, ho un problema lanciando una web application.
Contesto:
web application sviluppata utilizzando il framework JSF, application
funzionante (testata su apache e jetty).
Secondo step dello sviluppo è creare un'applicazione java che avvia il
web container jetty e rende disponibile il servizio (la web
application da me sviluppata) all'utente.
Ho trovato una marea di esempi su questa roba e in effetti l'avvio
dell'applicazione è ok se seguo testualmente l'esempio.
Terzo (e ultimo step) è lanciare lo stesso programma utilizzando
Reflection e RMI.
Ora la parte che riguarda la reflection va a buon fine (debuggo
regolarmente), riguardo l'RMI ho qualche problemino.
Premesso che su RMI ho fatto pochissimi esempi, ho preso spunto da
un'applicazione funzionante, modificandola e semplificandola secondo
le mie esigenze, riesco ad avviare in parte l'applicazione perchè si
blocca con questa bruttissima eccezione
java.net.BindException: Address already in use
	at sun.nio.ch.Net.bind(Native Method)
	at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:
119)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
	at
org.mortbay.jetty.nio.SelectChannelConnector.open(SelectChannelConnector.java:
198)
	at org.mortbay.jetty.AbstractConnector.doStart(AbstractConnector.java:
251)
	at
org.mortbay.jetty.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:
233)
	at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:
40)
	at org.mortbay.jetty.Server.doStart(Server.java:221)
	at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:
40)
Nell'applicazione io faccio solo un
LocateRegistry.createRegistry(9090);
Naming.rebind(getRegName(), application);
ovviamente application implementa java.rmi.Remote (per essere precisi
estende UnicastRemoteObject e implementa un'interfaccia che a sua
volta estende Remote).
ora la prima cosa che mi direte è "ma sei scema, hai un'altra istanza
sullo stesso indirizzo" ed è qui che casca l'asino, perchè il tutto
gira ancora in locale (sto sviluppando e testando) e soprattutto
quest'eccezione la ottengo appena acceso il pc (quindi teoricamente
non dovrebbe esserci niente di strano in esecuzione).
Per tacitare ogni dubbio questo è il risultato di netstat -anp
Proto Recv-Q Send-Q Local Address           Foreign Address
State       PID/Program name
tcp        0      0 
0.0.0.0:111
             0.0.0.0:*
LISTEN      -
tcp        0      0 
127.0.0.1:631
           0.0.0.0:*
LISTEN      -
tcp        0      0 
0.0.0.0:1720
            0.0.0.0:*
LISTEN      1692/ekiga
tcp        0      0 
127.0.0.1:25
            0.0.0.0:*
LISTEN      -
tcp        0      0 
0.0.0.0:40678
           0.0.0.0:*
LISTEN      2875/skype
tcp        0      0 
192.168.50.149:33575
 
209.85.229.19:443
ESTABLISHED 2749/google-chrome
tcp        0      0 
192.168.50.149:33156
 
209.85.229.83:443
ESTABLISHED 2749/google-chrome
tcp        0      0 
192.168.50.149:46334
 
93.145.110.158:17648
ESTABLISHED 2875/skype
tcp        0      0 :::111                  :::*
LISTEN      -
tcp        0      0 ::1:631                 :::*
LISTEN      -
tcp        0      0 ::1:25                  :::*
LISTEN      -
udp        0      0 
127.0.0.1:40402
0.0.0.0:*                           2875/skype
udp        0      0 
0.0.0.0:40678
0.0.0.0:*                           2875/skype
udp        0      0 
0.0.0.0:5353
0.0.0.0:*                           -
udp        0      0 
0.0.0.0:48879
0.0.0.0:*                           1692/ekiga
udp        0      0 
0.0.0.0:111
0.0.0.0:*                           -
udp        0      0 
0.0.0.0:631
0.0.0.0:*                           -
udp        0      0 
0.0.0.0:33185
0.0.0.0:*                           -
udp        0      0 
0.0.0.0:824
0.0.0.0:*                           -
udp        0      0 
192.168.50.149:5060
0.0.0.0:*                           1692/ekiga
udp        0      0 
0.0.0.0:68
0.0.0.0:*                           -
udp        0      0 
192.168.216.1:5060
0.0.0.0:*                           1692/ekiga
udp        0      0 
192.168.235.1:5060
0.0.0.0:*                           1692/ekiga
udp        0      0 :::
111                  :::*                                -
udp        0      0 :::
824                  :::*                                -
raw        0      0 
0.0.0.0:1
               0.0.0.0:*
7           -
e come potete vedere non ci sta niente in ascolto su localhost:9090
(che è come dovrebbe essere).
A questo punto mi chiedo, l'errore è nella gestione remota, ma cosa
sbaglio?     Please help me

 wrote:
Risolto, sbagliavo una roba allucinante nella configurazione
Grazie lo stesso :-)


A questo punto sarebbe carino dirci come hai risolto, no? :)
-- 
Dimitri De Franciscis
Phone:  
(+39) 3401570778
Website: 
http://www.megadix.it/

il problema principale di jetty è che c'è pochissima documentazione,
per cui trovare la causa di un errore e soprattutto capire per una
newbie come me quando l'errore è di programmazione e quando di
configurazione è una mezza impresa.
Se questo sistema lo devi embeddare è ancora peggio.
A parte svariati problemi con myfaces (che ormai ho risolto), il
sistema va a cercare la prima porta libera e su quella embedda jetty.
Il punto è che (errore mio nella stesura del programma in java) alla
fine di tutti i suoi conti prendeva la stessa porta per il binding rmi
(e falliva).
Il netstat aveva ragione ad essere libero, solo che non capivo io
perchè se ne andava tutte e due le volte nella stessa porta.
Alla fine ho fatto una prova settando a manina le porte ed è andato,
trovato l'errore correggere il codice è stato un passo :-)