Sysdent

Muchas veces he usado el objeto DialogBox de GWT para mostrar mensajes emergentes en vez de los intrusivos alerts, sin embargo siempre me había parecido que estos a pesar de tener una buena estética, no dan la impresión que lo que está detrás de él está congelado, entrando así en un problema de usabilidad en nuestras aplicaciones. Hoy, sin necesidad de estarlo buscando, me encontré con GWT Glass Pane, un composite que además se encarga de oscurecer el fondo de nuestra página al mejor estilo de LightBox.

En el sitio además explican como implementarlo de forma muy sencilla en nuestros proyectos, sin necesidad de tener que agregar un nuevo módulo a él, sino creando una clase nueva.

Pruebalo>>

Ya hace tiempo un amigo me enseñó como podía depurar mis aplicaciones web desplegadas en el servidor Apache Tomcat, este método me había venido funcionando perfectamente cuando usaba el tomcat iniciado con el script startup.bat o startup.sh, la cosa se complicó hace aproximadamente un mes cuando tuve que depurar un tomcat como servicio, en ese entonces tuve que buscar mucho sobre el tema, afortunadamente lo encontré, el día de hoy una compañera lo necesitó así que decidí colocarlo aquí en el blog por si alguién más lo llegase a necesitar.

La solución es bastente sencilla y basta con seguir los siguientes pasos:

• Abre una consola de MS-DOS y navega hasta la barpeta bin del tomcat, generalmente es C:\Archivos de programa\Apache Software Foundation\Tomcat6.0\bin.
• Estando ahí, ejecuta el siguiente comando: tomcat6w.exe //ES//tomcat6. Esto es equivalente a iniciar el monitor del tomcat, y presionar en la opción Configurar.
• Pásate a la pestaña de Java, y en la sección de Opciones de la máquina virtual (Java Options) escribe las siguientes 2 líneas:
  -Xdebug
  -Xrunjdwp:transport=dt_socket,address=127.0.0.1:1044,server=y,suspend=n
  Es muy importante que estás líneas queden en la primera posición, antes de las opciones que ya están ahí, como se puede ver en la imagen.
  el parámetro address, te dice la dirección y el puerto desde el que se conectará el eclipse, en este caso será un debug local y usaremos el puerto 1044.
  
• Presiona el botón aceptar y reinicia el servicio tomcat, con esto el tomcat iniciará en modo depuración.
• Ahora desde eclipse puedes configurar un perfil de depuración, solo tienes que dar click en el menú Run y luego en Debug Configurations.
• Agrega una nueva configuración de aplicación remota, seleccionando la opción Remote Java Application. Asigna un nombre para tu configuración y coloca la dirección IP de la máquina en la que se ejecuta el tomcat en el campo Host de la sección Connection Properties, tambien asígna el puerto que configuraste en las opciones de inicio del tomcat, en nuestro caso era el 1044 en el campo Port de la misma sección.
• En la pestaña Source selecciona tus proyectos mediante el botón Add, luego Java Project y selecciona los proyectos que quiera vigilar con el depurador.
• Ahora sólo nos hace falta colocar los puntos de depuración e iniciar el depurado mediante el botón Debug.

Eso es todo por ahora, espero que les sea de mucha utilidad.

En zeroturnaround realizaron hace poco una encuesta enfocada a conocer el uso de los servidores web java, principalmente con la idea de determinar que tanto tiempo gastamos desplegando, redesplegando y/o reiniciando el contenedor, este es un aspecto en el que la empresa trabaja, ya que son los productores del componente JavaRebel, encargado de apoyar el proceso de cargar los cambios del codigo al contenedor sin necesidad de redesplegar, según dicen ellos,  esto permite ahorrar hasta unos 5 minutos por cada cambio.

Pues en este momento se encuentran los resultados de la encuesta, hay que aclarar que no es palabra de Dios, sino simplemente lo que reflejan los datos recopilados durante el periodo que ha estado la encuesta en linea, esto es equivalente a unos 700 desarrolladores que la han respondido, es de destacar la supremasía de Apache Tomcat y también bastante curioso el poco uso de GlassFish.

Click en la imagen para ampliar los resultados

Da click en la imagen para bajar el video promocional

Ya se dió inicio a la tercera versión de la JavaCup, el torneo realizado por la organización de JavaHispano y otras empresas que buscar encontrar el mejor equipo de futbol programado en el lenguaje java. Personalmente me han gustado mucho este tipo aplicaciones que te permiten además de programar divertirte demasiado y si te esfuerzas incluso obtener alguna ganancia. Y es que en esta ocasión la cosa no es por sólo diversión, la organización en cabeza de Jorge Rubira junto con las demás empresas patrocinadoras han preparado suculentos premios para quienes se ubiquen en los primeros lugares, así:

1. 1.000 Euros y una subscripción por un año a la revista solo programadores.
2. 500 Euros y una subscripción por un año a la revista solo programadores.
3. 250 Euros y una subscripción por un año a la revista solo programadores.
4. 125 Euros y una subscripción por un año a la revista solo programadores.

Si deseas participar, tienes plazo hasta el día 31 de Mayo del presente para enviar tu táctica, es bueno aclarar que sólo se admitirá un equipo por persona. Puedes consultar las demás bases del concurso aquí.

Si usas eclipse como entorno de desarrollo, puedes bajar el proyecto listo para importar acá, o si lo prefieres con NetBeans puedes hacerlo desde acá.

También es posible descargar la documentación del framework y un pequeño tutorial acá.

Mi impresión personal es que el framework ha ido madurando y ya toma una forma más atractiva tanto para el programador como para el espectador, también quiero anunciarles que Sysdent tendrá su equipo para esta competencia y que si alguno desea unirse para tratar de mejorar la táctica será bienvenido al grupo.

La invitación también es para todos los desarrolladores Java de Colombia, especialemente a mis colegas de la comunidad de Dragonjar para que se involucren de alguna forma, este tipo de eventos nos permite mostrar de lo que somos capaces mientras nos divertirnos un poco.

Visitar la web de la JavaCup.

No se puede negar que muchos de los que día a día trabajamos con Java Enterprise Edition usamos las páginas JSP como el objeto más sencillo para manejar presentación, pero muchas veces por puro desconocimiento terminamos haciendo cosas realmente complejas para solucionar problemas que podrían haber sido más sencillos.

Algo que muchos creemos conocer pero que en la práctica casi desconocemos son los objetos implicitos que podemos usar dentro de las página JSP, más especifícamente en las expresiones, así que he decidido realizar un pequeño resumen de los objetos implicitos de las JSP y su pricipal uso:

• pageContext: Como su nombre lo dice es el contexto de una página JSP, y es el medio por el cual podremos acceder a otros objetos como: servletContext, session, resquest y response.
• servletContext: Representa el contexto del servlet que se generará a partir de la página JSP, este provee el acceso para los parametros de inicialización, recursos asociados con el contexto web, los llamados parametros de alcance de aplicación y algunas características de loggin.
• session: Es el objeto que nos permite almacenar datos relacionados con el estado del usuario, comunmente conocido como sesión. basicamente nos permite accesar y asignar los parámetros relacionados a la misma.
• request: Contiene toda la información transferida desde el cliente hasta el servidor com son: parámetros, información sobre el protocolo usado para la comunicación y información relevante a la localización o datos especificos del cliente, lenguaje usado, dirección ip de acceso, etc.
• response: nos provee el acceso al objeto por el cual se envía la respuesta al cliente, esto nos permite por ejemplo modificar el tipo de contenido a entregar, por ejemplo si quisieramos generar un documento pdf o un comprimido de manera que el navegador pueda interpretar el tipo de respuesta. Personalmente recomiendo no tocar este objeto desde una JSP a menos que sea estrictamente necesario.
• param: Es un conjuto de objetos del tipo clave=valor, útiles para accesar datos correspondientes a la solicitud, por ejemplo al usar param['user'], estariamos accediendo a un parámetro llamado “user” del objeto request.
• paramValues: Igual que el anterior pero el tipo de retorno no es un objeto simple sino un array de objetos.
• header: Permite obtener el valor de un encabezado indicando su nombre, ejemplo: header['content-type'] nos retorna el tipo de contenido que genera la página.
• headerValues: Igual que el anterior pero su tipo de retorno es un array de objetos.
• cookie: Nos permite obtener on objeto cookie a partir de su nombre.
• initParam: Permite acceder a los parámetros de inicialización de los servlets, si esos que se indican en el descriptor de despliegue más conocido como web.xml.
• pageScope: Permite acceder a una variable cuyo alcance es la página, a partir de su nombre.
• requestScope: Permite acceder a una variable cuyo alcance es la petición, a partir de su nombre.
• sessionScope: Permite acceder a una variable cuyo alcance es la sesión del usuario, a partir de su nombre.
• applicationScope: Permite acceder a una variable cuyo alcance es a aplicación o contexto web, a partir de su nombre.