El código asociado a las demos lo pueden ver acá

¿¡Qué!? No que yo odiaba Java?

Bueno, no precisamente. Sí pienso que es usado para muchas tareas en las que un lenguaje más poderoso debiera ser usado. Por ejemplo, pienso que hacer desarrollo web en Java en el 2011 es similar a haber hecho desarrollo web con C en 1997. Pero aún pienso que es un buen lenguaje para programación a nivel de sistemas y que tiene una impresionante plataforma en la JVM.

Así que no es raro que yo esté dando una charla mañana en el Java Day Osorno. Voy a hacer dos charlas, una de ellas titulada “El lado cool de java” en la cual mostraré las características modernas de Java que todos los proyectos modernos debieran usar pero, hasta donde veo, no son usadas porque la gente no sabe de ellas. O quizás están pegados en una versión antigua de Java. Pero aún así, saber de Java 6 es bueno (y puede ayudar en poner presión sobre los desarrolladores pegados en el pasado para volver al presente)

La otra charla será una charla introductoria de Ruby. Yeah, puede sonar extraño hablar acerca de Ruby en un evento de Java, pero es uno de los beneficios de ser un charlista . Pienso que haciéndola, podría estar salvando al mundo de algunas líneas de Java que debieran ser implementadas en un lenguaje más expresivo. Y poner JRuby en la mezcla va a hacer que todo quede perfectamente justificado

Lee este post en inglés

Depurar, a través de Eclipse, aplicaciones web java es de gran utilidad. Permite visualizar valores de variables en tiempo de ejecución, además de poder trazar exactamente las partes de código por donde corre la aplicación. Para que funcione, Eclipse debe ser el encargado de correr el servidor de aplicaciones que usemos.

Pero que sucede cuando no nos es posible integrar el servidor dentro del IDE, ya sea por que el servidor se encuentre en una máquina distinta a la nuestra o simplemente por que no quieras que Eclipse gestione el servidor.
Para lograr depurar en estos casos, se usa el “Remote debugging” o mejor conocida como depuración remota en estos lados del planeta.

Primero que nada, debemos configurar nuestro servidor para habilitar la depuración remota. La magia de esta opción recae en las siguientes líneas:

-Xdebug
-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

Lo escrito en address=8000 corresponde al puerto de conexión a usar para depurar, en este caso es el puerto 8000.
Ahora, donde agregar estas líneas, depende de cual sea tu servidor de aplicaciones y de que manera lo inicies. Para este caso detallare como configurar Tomcat y Jetty, los que tienen distintas maneras de configurar, pero al fin y al cabo siempre cumplen el mismo propósito.

Tomcat

Se puede cambiar el script de ejecución de tomcat ubicado en:

$CATALINA_HOME/bin/catalina.sh (en linux)
$CATALINA_HOME/bin/catalina.bat (en windows)

Luego en este archivo debemos buscar la variable JAVA_OPTS (o crearla en caso de no existir) y agregar la configuración mencionada anteriormente, de tal manera que quede en una sola línea:

En linux

JAVA_OPTS="$JAVA_OPTS "-Xdebug" "-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

En windows

set JAVA_OPTS=%JAVA_OPTS% -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

“$JAVA_OPTS ” y %JAVA_OPTS% sirven únicamente para conservar otras opciones de java que se hayan agregado con anterioridad, así no reemplazarlas con nuestros cambios.

Existe un par de opciones extras para windows (si, a veces lamentablemente debes lidiar con el tío Bill). Una de ellas es agregar las opciones a través de la pantalla de propiedades del monitor de tomcat (Esto funciona independiente que tengas o no corriendo tu tomcat como un servicio de windows).

Aquí se debe poner suma atención a los espacios que puedas poner al fin de cada línea, esta configuración es susceptible a espacios y si encuentra uno demás, no tomará esas opciones como válidas. Para evitarte problemas, copia y pega el código del inicio.

La segunda opción es ir a configurar estos parámetros directamente en el registro de windows, en la ruta:

HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 2.0\Tomcat6\Parameters\Java (Para tomcat 5 es igual, solo cambiar “Tomcat6″ por “Tomcat5″ en ruta del registro)

Luego entras a modificar la clave “Options” y agregas las dichosas líneas.

Jetty

En jetty, es necesario pasar los parámetros de configuración al correr el servidor. Para mi lo más simple fue crear un script que ejecute el siguiente comando:

java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8125,suspend=n -jar start.jar

Ahora después de todo esto, ¿Como saber que está funcionando?. Simple, al iniciar nuestro servidor de aplicaciones, dependiendo de cual hayas configurado, saldrá algo como lo siguiente:

Tomcat en windows

Jetty en linux

Si te fijas, en la primera línea sale Listening for transport dt_socket at address: XXXX. Acá indicará cual puerto configuraste para depurar. Si te sale esto, felicidades, has completado la primera parte.

Eclipse

Luego por el lado de Eclipse, debemos configurarlo para que pueda conectarse al servidor de aplicaciones. Para esto vamos al ícono de Debug (el del bicho verde) y abrimos la ventana de depuración

En esta ventana debemos crear una nueva configuración del tipo “Remote Java Application”, donde los campos importantes a ingresar son:

• El proyecto a depurar (obviamente donde se encuentre el código fuente)
• Host o dirección ip de la máquina donde corre el servidor
• Puerto configurado para depurar

Finalmente presionamos “Debug” para realizar la conexión al servidor. Si todo resultó como se esperaba, en la vista “Debug” de Eclipse, deberá aparecer la conexión ya establecida.

Terminado esto, ya puedes comenzar a poner breakpoints y depurar tu aplicación.