ßeta perpetua

El blog personal de Juan Manuel Barroso

Contexto de una aplicación en JBOSS

enero 27th, 2012 Posted in Desarrollo, jboss
ene, 27 2012
No Comments »

El contexto raíz de una aplicación web determina las URLs que serán delegadas por el servidor a nuestra aplicación, esto quiere decir que si tenemos un contexto raiz myapplication el servidor delegará a nuestra aplicación todas las peticiones del tipo myapplication/*.

El contexto raíz se carga durante el despliegue, y dependiendo del tipo de artefacto (EAR,  WAR) puede encontrarse en lugares diferentes.

Cuando estamos trabajando con un EAR el contexto de la aplicación debe ser especificado en el fichero application.xml, específicamente en la etiqueta <context-root/> del módulo correspondiente:

Si nuestra aplicación va a ser desplegada en un .war directamente, debemos modificar el fichero jboss-web.xml de la carpeta  WEB-INF:

<application xmlns="http://java.sun.com/xml/ns/j2ee" version="1.4"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://java.sun.com /xml/ns/j2ee 
                             http://java.sun.com/xml/ns/j2ee/application_1_4.xsd">
    <display-name>MyApplication</display-name>
 
    <module>
        <web>
            <web-uri>myApplication.war</web-uri>
            <context-root>myNewContext</context-root>
        </web>
    </module>
 
    <module>
        <ejb>my-library.jar</ejb>
    </module>
 
</application>

Si nuestra aplicación va a ser desplegada en un .war directamente, debemos modificar el fichero jboss-web.xml de la carpeta WEB-INF:

<jboss-web>
    <context-root>myNewContext</context-root>
</jboss-web>

De esta manera las peticiones a myNewContext/* serán delegadas a nuestra aplicación.

Si no especificamos un contexto al WAR, se usará el mismo nombre del fichero .war. Por ejemplo, para el desplegable otra-aplicacion.war se usará el contexto otra-aplicacion.

Esto puede ser útil cuando necesitemos publicar nuestra aplicación en una ruta del tipo: producto/consolas/myAplicacion.

Un caso real donde tuve que cambiar el contexto de una aplicación, fue desplegando un aplicación Grails que delegaba la parte de seguridad en SpringSecurity y sólo podía ser accesible desde una redirección de Apache. El problema era que el plugin no era capaz de redirigir desde la página de login a la primera página de la aplicación. Como solución inmediata cambie el contexto de la aplicación para que coincidiera con la URL de la redirección y problema solucionado.
Probablemente el plugin podía ser configurado para solucionar el problema, pero en aquel momento la aplicación debía estar en producción sin retrasos.

Probado con JBOSS 5 y Grails 1.3.7

Read More

Señales visuales, ¡grandes aliadas!

noviembre 10th, 2011 Posted in Herramientas
nov, 10 2011
4 Comments »

La primera vez que escuche eso de las “señales visuales” fue hace un año atrás, en un curso de Scrum Manager con Juan Palacios y Claudia Ruata. La verdad que en aquel momento no terminé de captar la esencia, mira que nos cuesta entender a los informáticos que hay cosas que están mejor  fuera de una aplicación o del e-mail.

DEFCON en nivel 5. Sólo el día del sorteo de la lotería de navidad fue visto así.

La primera señal que tuvimos, sin saber que realmente era un señal, fue un DEFCON recortable. Todo empezó a modo de chiste pero sin darnos cuenta se convirtió en un medidor del estado de estrés del equipo. Los fallos en producción, las neuras del cliente o sencillamente el sorteo de la lotería de navidad alteraban el estado del dichoso trozo de cartón.

Y cuando presencié intercambio de opiniones (a.k.a discusiones) sobre el nivel que debía tener el DEFCON en función de las “cosas” que el proyecto tenía pendiente, empecé a entender lo que Juan y Claudia querían transmitirnos.

Las señales visuales transmiten el estado del proyecto de manera general y natural, no deberíamos tener que abrir una aplicación o revisar el correo para saber si la aplicación de producción se ha caído, o abrir la aplicación de gestión de tickets y lanzar una consulta para ver que tenemos un cuello de botella en las tareas de testing planificadas.  En lugar de esto podemos buscar una pantalla vieja y poner un radiador de información que ponga la pantalla roja cuando la aplicación se ha caído o una pizarra kanban/scrumban que muestre de manera global las tareas acumuladas. Herramientas como estas se camuflan en la oficina y nos transmiten información de manera transparente, al levantarnos para ir al baño, al parar para hablar con un compañero o sencillamente cuando estemos tomando un café.

Sólo tenemos que estar atentos a cosas que podemos expresar visualmente y dedicar un instante de tiempo a implantarlas. Lo mejor es comenzar por cosas sencillas, y es importante que no moleste de manera directa a un compañero. No quitarle espacio de trabajo por ejemplo.

En mi caso instalé el radiator plugin en Jenkins, la intención era tener de manera muy visible el estado de los entornos. La instalación no llevo más de 15 minutos y aporta una información muy valiosa al equipo. Ya no tenemos que mirar el correo para ver si nuestra plataforma tiene problemas, ahora somos más rápidos detectando problemas (lo de corregirlos es otro tema :p) y hemos descargado nuestra cabeza de la presión de mirar los correos para ver si los entornos se encuentra estable.

La pantalla está en un lugar visible para todo el equipo y muestra el estado de los test de monitorización lanzados por Jenkins

Algunas cosas no funcionarán como esperas, no tendrán el efecto deseado, pero eso no debe ser un impedimento para intentar mejorar cada día nuestro trabajo y el del equipo. Mi corta experiencia me dice que no siempre debemos pedir aprobación pues muchas veces nos dirán que es una perdida de tiempo, debemos lanzarnos con cosas pequeñas y simples como un DEFCON , plugins para las herramientas de integración continua (también valen las señales acústicas) o incluso usar una pizarra grande para marcar lista de objetivos que se necesitan conseguir a muy corto plazo y donde vamos tachando los conseguidos.

Por cierto, me olvide de decir que el primer DEFCON fue idea de @jjcoellov y lo consiguió en Microsiervos.

 

Edito: Para entender el vídeo anterior tenemos que ver Toy Story 3 o el siguiente vídeo:

 

, ,
Read More

Grails: Testing unitario de controladores que usan ‘bindData’

octubre 15th, 2011 Posted in Desarrollo, Grails, Testing
oct, 15 2011
No Comments »

Grails permite hacer data binding en las acciones de los controladores. Es una manera muy práctica de cargar los parámetros que nos llegan a través de los submit de los formularios a objetos de dominio.

El problema lo tenemos con los test unitarios de nuestro controlador. Al lanzarlos no se encontrará el método bindData, y obtendremos un error del tipo “No signature of method:….”

Para evitar este problema podemos inyectar el método bindData al objeto controlador que estamos probando unitariamente. A continuación se muestra un código que realiza dicha tarea:

private void addBindataToController() {
  controller.metaClass.bindData = { objectInstance, params ->
     def excludeProperties = ['class' , 'metaClass' ]
     params.each { property, value ->
       try {
         if(!excludeProperties.contains(property)) {
           objectInstance."$property" = value
         }
       } catch(MissingPropertyException ex){ }
     }
     return objectInstance
  }
}

Sólo debemos añadir el  método anterior a la clase en la que implementamos  las pruebas unitarias de nuestro controlador, e invocarlo en el setup de nuestros test.

Con esto podemos saltarnos la limitación de hacer testing unitario sobre controladores que usan el método bindData. Este limitación ha estado presente, al menos, hasta la versión 1.3.7 de Grails. Es muy posible que futuras versiones del framework den solución al problema.

,
Read More

Useful Tips: VIM – Guardar cambios fichero sólo lectura

junio 26th, 2011 Posted in Useful Tips
jun, 26 2011
No Comments »

Hay fallos en los que soy muy recurrente, uno de ellos es editar ficheros del sistema sin haber hecho el previo sudo.

Si usamos VIM podemos hacer el sudo sin tener que salir de la edición, y por tanto sin perder nuestros cambios, para ello tecleamos en modo comando lo siguiente:

:w !sudo tee %

Gracias a @fran_reyes por el tip!

Más información sobre el comando tee aquí.

,
Read More

Conectando Grails y EJB3

junio 1st, 2011 Posted in Desarrollo, Grails
jun, 01 2011
No Comments »

Me he encontrado con la necesidad de construir una aplicación web sobre un servicio EJB3 que implementa el acceso a datos y gran parte de la lógica de negocio, y como era de esperar, Grails me ha facilitado enormemente el mecanismo para la integración.

La idea es que la aplicación Grails (1.3.6) pueda desplegarse en un servidor diferente a donde se encuentra el EJB3, para esto usaremos  JNDI y la interfaz remota del servicio.

Lo primero que debemos hacer es añadir los beans correspondientes al fichero conf/spring/resources.groovy:

ejbJndi(org.springframework.jndi.JndiTemplate) {
   environment = [
      "java.naming.factory.initial" : "org.jnp.interfaces.NamingContextFactory",
      "java.naming.provider.url" : "jnp://servidorEJb3.net:1099"
   ]
}

Lo que hemos hecho es construir un bean, con nombre ejbJndi, a partir  de la clase org.springframework.jndi.JndiTemplate. Le damos valor a la variable environment especificando las propiedades que Spring usará para encontrar nuestro EJB3.

Luego procedemos a declarar nuestro bean remoto añadiendo al fichero anterior una nueva entrada:

beanServicioRemoto(org.springframework.jndi.JndiObjectFactoryBean) {
    jndiName = "aplicacion/ejbName/remote"
    jndiTemplate = ref("ejbJndi")
}

Hemos llamado a nuestro bean beanServicioRemoto, y lo hemos inicializado con el nombre del EJB (especificando la interfaz remota)  y la referencia a nuestro template  ejbJndi.

El beanServicioRemoto puede ser usado desde los controladores o servicios como un servicio más: 

def beanServicioRemoto

Pero antes de poder usarlo debemos añadir algunas librerías al directorio lib de nuestra aplicación:

La primera a añadir deberá ser la que contenga la interfaz del EJB3 remoto y todos las clases que se usen en dicha interfaz. Dicha librería puede obtenerse empaquetando en un JAR las clases del EJB3

Adicionalmente, es muy probable que se necesiten añadir librerías clientes del servidor donde se encuentre desplegado el EJB3. Para JBOSS 4.2.3 se han añadido las siguientes librerías:

jbossall-client.jar
jboss-aop-jdk50-client.jar
jboss-aspect-jdk50-client.jar
jboss-common-client.jar
jboss-ejb3-client.jar
jboss-j2ee.jar
jnp-client.jar

Si la aplicación levanta, enhorabuena, en caso contrario es muy probable que aparezca el demonio de los conflictos de librerías y tengas que pelearte con él. En mi caso me apareció el siguiente error:

Server failed to start: java.lang.LinkageError:
   Class javax/management/MBeanServer violates loader constraints

Problema que solucione cambiando el servidor de aplicaciones embebido a jetty. Este cambio me lo pude permitir porque el contenedor destino de la aplicación  era JBOSS, y en tiempo de desarrollo me daba igual tomcat que jetty.

Para desinstalar tomcat e instalar jetty:

grails uninstall-plugin tomcat
grails install-plugin jetty

Si en lugar de EJB3 tenemos EJB2 se deberán cambiar las clases de Spring que se usan en el resources.groovy. Puede consultarse aquí dicho escenario.

,
Read More

¡Enciendan maquinas!

noviembre 6th, 2010 Posted in Personal
nov, 06 2010
No Comments »

Demasiado tiempo ha pasado desde que tuve la idea de crear este sitio hasta tenerlo operativo, me costo encontrar un diseño que no me disgustara y mucho más  robarle algunas horas a la universidad, al trabajo y a la vida social para montar este tinglado.

Ahora no queda más que intentar darle forma, no tengo claro la forma que espero conseguir pero comenzaré plasmando ideas, recetas e incluso algunas de esas diarreas mentales que con alguna frecuencia inundan mi cabeza. Es muy probable que se toquen temas diversos, en ocasiones puede que tengan poca o ninguna conexión pero la mayoría girará en torno a la tecnología y al desarrollo de software.

Ponemos la maquinaría en marcha y  esperamos no morir en el intento.

Read More