Exception running Jetty
valia
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
valia
Risolto, sbagliavo una roba allucinante nella configurazione
Grazie lo stesso :-)
Dimitri De Franciscis
A questo punto sarebbe carino dirci come hai risolto, no? :)
--
Dimitri De Franciscis
Phone: (+39) 3401570778
Website: http://www.megadix.it/
valia
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 :-)