Siguiendo con el post anterior, dos días de trabajo después, creo que he conseguido solucionar todos los problemas que tenía. Debo una o más entradas en la Chuwiki contando todos los detalles ….
Las pegas, muchas y variadas. Un resumen de ellas.
Lo primero es que con la librería jaxmpp2, y supongo que con cualquier otra librería de javascript que se conecte con un servidor de chat XMPP sobre http, acaba llamando al servidor de chat con la misma URL en la que está ubicada la librería, por lo que es necesario montar en nuestro servidor apache un servidor virtual que redirija ciertas llamadas al servidor de chat. Con el servidor apache es fácil, ya que soporta en su fichero de configuración http.conf este tipo de cosas. Con un servidor de aplicaciones como Tomcat es necesario quizás montar un servlet que haga esta redirección, como JabberHTTPbind. Estas redirecciones hacen, por ejemplo, que sea muy difícil arrancar con eclipse y un servidor interno nuestra aplicación GWT.
Segundo problema, por más que probaba en google chrome, no había manera de conseguir la conexión. El problema es el de las peticiones "cross-site". Los navegadores, por seguridad (evitar el cross-site scripting) ponen restricciones a las páginas que se cargan de un lado, ejecutan scripts de otros sitios y modifican el html de la página (o algo así de retorcido). El caso es que entre que el código javascript generado por GWT está en un servidor y el Openfire es otro servidor, y encima hay una redirección de host virtual entre medias, google chrome no deja ejecutar el código javascript…. ¡¡¡¡ y ni siquiera avisa !!!!. Simplemente, no funciona y no lo ves salvo que abras el debugger de javascript que viene con el navegador. En este sentido al menos, el maligno es algo más amigable. Saca un aviso indicando el problema y dándote opción a ejecutar el código de todas formas. Afortunadamente, después de unas horas para descubrirlo, tiene fácil arreglo. Basta llamar a todos los servidores con el mismo nombre (la url del navegador, el del host virtual y el de openfire).
Y la última estupidez. Tras conseguir hacer funcionar lo básico de mi aplicación de chat, a los 30 segundos o así se desconecta ella soiita del servidor. Este problema casi me hace dejar el asunto e intentarlo de otra manera, no veía el motivo de la desconexión, sobre todo cuando aparentemente era provocado por un mensaje procedente del servidor openfire. Pero sonó la flauta. Tras una tarde de pruebas e intentar depurar el código de la librería, me doy cuenta que la primera vez que arranco openfire y mi aplicación funciona bien, es en los siguientes arranques de mi aplicación (sin rearrancar el servidor de chat openfire) cuando ocurre la desconexión a los 30 segundos. Pues bien, tirando del hilo acabo de descubrir que es por no cerrar las conexiones. Si voy arrancando la misma aplicación varias veces (o matándola y rearrancándola), las conexiones anteriores con el mismo usuario/password quedan abiertas y openfire no debe admitir dos sesiones iguales con el mismo usuario y password, por lo que las va cerrando.
Lo dicho, por fin creo tener resueltos todos los problemas (o casi, me queda ver cómo cerrar la conexión) y un mini-cliente-chat básico funcionando, para seguir desarrollando pero ya sólo los detalles. Creo que todo esto me dará para un par de artículos en la chuwiki, uno sobre los host virtuales de apache y el http-bind (nombrecito que se da a la conexión de chat xmpp sobre http) y otro sobre lo básico de la librería jaxmpp2.
Pingback: de la red – 1/05/2011 « Tecnologías y su contexto
Pingback: Diario de Programación » Blog Archive » Y finalmente, haciendo un servidor de chat (III)