Assuming you are going to release more frequently, what is likely to happen? In this talk I present sketch quarterly deployment, monthly deployment, weekly deployment, daily deployment, and finally hourly deployment, including the technical, social, and business implications.
Fecha: Tuesday, November 3, 2009
Hora: 19:00 GMT
Duración: 1 hour

El curso de TDD fue muy bueno, Naresh demostró la importancia de tener un mecanismo de evaluación constante y automatizado para tener siempre una retroalimentación del estado del producto, aplicó el concepto de TDD con analogías sencillas sin alejarse de los casos reales de desarrollo de software y fue muy pragmático todo el tiempo.
Al finalizar el curso, salí con una idea mucho más clara sobre el significado de Unit Testing, sus beneficios, mitos y limitaciones. Los temas que se tocaron fueron en un principio XP, Pair Programing, Metodologías Agiles, Test Driven Development, Test Driven Design, Code Smells y Automated Refactoring, para después sumar herramientas para aplicar tanto TDD como BDD. Entre cada tema se plantearon cuales son los errores comunes, los patrones de diseño y las implementaciones en diferentes lenguajes: Java, .Net principalmente, pero sin dejar de lado Python, C/C++, Ruby entre otros. Cabe destacar que por la cantidad de los temas tratados, todos los participantes concluimos que el título designado “Test Driven Development (TDD) and Refactoring” no era el adecuado, puesto que el mismo no daba a conocer la totalidad de la temática del curso.
Los seminarios que presencié los días restantes fueron muy variados.
Los mas destacados fueron:
* A cargo de Alejandra Alfonso y Emilio Gutter escuché sobre experiencias en implementaciones de metodologías agiles en un grupo multicultural y remoto.
* Un Coding Dojo y un Testing Dojo, el CO a cargo de Ivan Sanchez y Victor Hugo Germano y el TO a cargo de Jorge Alberto Diz, ambos excelentes.

Todo esto potenciado por la participación de Brian Marick, Diana Larsen, Roy Singham, David Hussman, Joshua Kerievsky, Dave Nicolette y sus respectivos key note, cursos y/o charlas.

En conclusión, una experiencia muy completa desde lo profesional y lo personal de la que no dejé de aprender en cada minuto.

Espero poder sumarme al equipo y vamos por Agiles 2010 empujando los limites tecnológicos de América Latina demostrando que acá también podemos tener eventos de vanguardia y de excelente calidad.

Un ‘mil gracias!’ para todos lo que hicieron posible Agiles2009 en especial a Alejandra Alfonso, a Juan Gabardini, a Victor Hugo Germano por la buena onda. Y uno mucho mas especial a Romina Cordoba, que sin ella no podría haber participado de todo esto ;)

You see it in their faces
The sadness in their tears
The desperation and the anger
Madness and the fear

No hope, no life, just pain and fear
No food, no love, just greed is here

Starvation and the hunger
The suffering and the pain
The agonies of all-out war
When will it come again?

The struggle for the power
A tyrant tries again
Just what the hell is going on?
When will it ever end?

No hope, no life, just pain and fear
No food, no love, just greed is here

You see the full moon float
You watch the red sun rise
We take these things for granted
But somewhere someone’s dying

Contaminated waters
Pollution and decay
Just waiting for disease to strike
Oh will we learn someday?

No hope, no life, just pain and fear
No food, no love, no seed
childhood’s end

Disfruten.

La charla es una introducción y estará orientada a programadores Jrs con contenido teórico y ejemplos prácticos pero invito a cualquier PyME interesada en conocer las últimas tendencias de los frameworks J2EE, el desarrollo orientado a componentes.

Este nerd se va para Agiles 2009, aguante

http://www.cultofmac.com/icon-porn-feast-your-eyes-on-snow-leopards-beautiful-icons/15764/7

Sebasjm

• 1 Introducción
  • 1.1 Objetivos
• 2 Behavior Driven Development
• 3 Caso de uso
  • 3.1 Introducción
  • 3.2 Requerimientos
  • 3.3 El Analista: Relevando el comportamiento
  • 3.4 La herramienta: JBehave en acción
    • 3.4.1 Escenarios: Cómo debería comportarse la aplicación
    • 3.4.2 Pasos: Partes concretas del test
  • 3.5 Interacción entre roles
• 4 Conclusión
• 5 Enlaces
  • 5.1 Software Java
  • 5.2 Software .Net
  • 5.3 Documentación
  • 5.4 Ejemplos de utilización
• Bibliografía adicional

Dado Un contrato pospago
Cuando Intento activar el servicio
Entonces La validación termina sin errores

Given Un contrato pospago
When Intento activar el servicio
Then La validación termina sin errores

public class ValidacionServicio extends Scenario {

    public ValidacionServicio() {
        super( new PasosDeValidacion() );
    }
}

public class PasosDeValidacion extends Steps {

}

    @Given("Un contrato pospago")
    public void crearGestionyContratoPrepago(){
       // ... generar contrato y asociarlo a la forma de pago POSPAGO ...
    }
   
    @When("Intento activar el servicio")
    public void validarActivacion() {
       // ... invocar la validación y obtener el estado de la operación ...
    }
 
    @Then("La validacion termina sin errores")
    public void assertTerminaSinErrores(){
        // ... asegurar o verificar que el escenario cumpla con un estado en particular ...
        ensureThat(!validacionTerminaConErrores);
    }

Given Un cliente cualquiera
Given Un contrato pospago
When Intento activar el servicio
Then La validacion termina sin errores

Given Un contrato prepago
When Intento activar el servicio
Then La validacion termina con errores
 
When Intento desactivar el servicio
Then La validacion termina sin errores

Given Un cliente cualquiera
Given Un contrato hibrido
When Intento activar el servicio
Then La validacion termina con errores

Given Un cliente cualquiera
Given Un contrato prepago
When Intento activar el servicio
Then La validacion termina con errores

Given Un cliente cualquiera
Given Un contrato prepago
Given Un contrato hibrido
Given Un contrato pospago
When Intento desactivar el servicio
Then La validacion termina sin errores

gmail server error

Woooooooooow…
Si comparas esto con tirar una bomba, y tomas como parametro la cantidad de personas afectadas.
Cual sería el equivalente?

Huele a DoS

dos

La pregunta es: ¿Porque estoy usando windows?

Situacion:
Tenés un proyecto hecho con Ant con build.xml, properties y directórios obscuros por todos lados y resulta que desde que te pusistes a utilizar _ese_ desktop que tenés ( que ademas tiene windows ) nunca instalaste Ant ( bien ahí ), en cambio fuistes por más y utilizaste siempre Maven 2

Opciones:
1.- Lo que te dice la lógica y Alejandro Wiebe: bajar 11 megas de la Red por el proxy feo que tenés.
2.- DeSSScompilás un proyecto parecido a Ant y te armás uno parecido que cumpla con tu necesidad
3.- Vas por el camino fácil y escribís esto en un pom.xml dentro del mismo directório

</project>


desde la consola
mvn antrun:run

y sos feliz.

El ejemplo es de Mojarra y el plugin de antrun pesa unos míseros 24k.

Chuck Norris Certified

Perdón, pensando en ‘voz alta’… ahora los voy a introducir al problema. Imaginen esto, tienen una página que muestra el estado de tu transacción… viva imagen del estado de un SFSB en la conversación en curso. Ahora, cuando termina la transacción ( sea por cancelación o confirmación ) el SFSB desaparece llevándose consigo su información, por ende esta será inaccesible para la siguiente vista. Salvo… que uses Seam.

Caso 1: dentro de una conversación larga ( o long running conversation ( aka conversaciones manuales ) )

Cuando terminamos una transacción cerramos la operación con un método anotado con @End. La conversación por defecto no termina ( o mejor dicho ‘el contexto conversacional no se destruye’ ) cuando finaliza el método de la aplicación si no que se mantiene hasta que el último componente de la página haya sido renderisado. Por ende hay un instante, entre que finalizó la operación y la próxima página se está renderisando en que la conversación tiene un SFSB accesible pero invalido.

* la misma conversación/transacción se mantiene aunque nuestra transacción lógica/de negocio terminó

Por suerte tenemos una manera cambiar este comportamiento y es diciendolé a Seam que termine la conversación antes de que redirija el browser a otra página para mostrar los resultados.

* una nueva conversación/transacción se crea luego de la redirección

Toda esta facilidad se pierde cuando tenemos no hacemos una redirección de la aplicación. Como resultado vamos a ver que aunque le demos ‘terminar’ a la transacción y teoricamente haga flush de todos los datos vamos a ver la respuesta en un estado inconcluso.

Por ejemplo, imaginemos una aplicación en la que generamos una lista de pedidos con un wizard, la lista estará asociada a la conversación en curso, cuando llegamos a la última página de este wizard nos muestra una lista con los pedidos a realizar y luego de persistir los datos, como todos los cambios fueron confirmados, la próxima página muestra una lista vacia simbolo de que no hay pedidos sin hacer. Si no toman en cuenta estas particularidades se pueden encontrar con que una vez terminada la transacción la página de respuesta muestra los valores de una conversación/transacción que le dijimos que termine, y cuando volvemos a hacer un request para que nos vuelva a mostrar la misma información esta desaparece. Esto es porque lo que se termina generando como resultado no refleja el estado del contexto en el servidor una vez que se cierra la conversación y esto es después de que toda la página haya terminado de mostrarse.

Si les gustaron mis dibujos les dejo otro para que vean que pasa si no usamos redirección. 

* si no hay redirección el proceso de renderisado se hace con una conversación invalida

Caso 2: fuera de una conversación larga ( conversaciones por defecto )

En este caso Seam no nos da tregua y me pareció muy frustrante. Solo las conversaciones largas ( las que son iniciadas manualmente con @Begin o similares ) pueden ser finalizadas manualmente. Por eso entré al blog pensado que el problema es que no hay una manera de forzar la destrucción de un contexto, o de invalidarlo, hay que marcarlo y esperar que el motor de Seam decida cuando limpiar.

Igual, no desesperen encontré un workaround ( un parche ) para llevar este caso al anterior :

Manager.instance().setLongRunningConversation( true );

Conversation.instance().endBeforeRedirect();

No es muy bonito que digamos, pero nos permite salir del paso. Hice un post en el foro oficial a ver que me responden los gurues del tema. Cualquier noticia los tengo al tanto. Saludos.

hay gente que solo usan una tecnología, la aprenden y le sacan jugo ( y ya tenemos un grupo reducido )

otros… aportan cuando lo creen necesario… ( damm few! )

los que se seban y tienen tiempo se dedican a un proyecto personal… ( por suerte siempre aparece un nuevo )

otros… apuntan alto, tuercen la matrix a su favor y la reman contra viento, marea y tortugas ninjas inclusive, como el maestro salaboy… un ejemplo!

Fuerza argenta para vos man! Trae regalos =D

salaboy.wordpress.com

He aquí… con ustedes… les presento…

JBug Argentina

No se lo pierdan, próximamente en las mejores salas.

Estuve trabajando un poco con reflection, una de las características mas fuerte de Java y poco explotadas que si son bien manejadas pueden construirse lindos frameworks como Spring, Seam o implementar el stack de EJB. Por el otro lado, el exceso del uso impacta directamente en la performance de la aplicación y si estamos haciendo cosas complejas utilizando Proxies podemos perdernos y el flujo de ejecución termina lejos de donde esperabamos.

Vamos a ver de que hablamos cuando hablamos de reflection. Aclaro que lo que vallan a leer es solo por la experiencia de uso, no soy ningún experto en la materia, así que cualquier corrección es bienvenida.

Supongamos que tenemos una tarea simple, le queremos listar todas las posibles acciones que nuestro EJB puede hacer al consumidor. Obviamente la primera respuesta es tenerlo en archivo de configuración posiblemente un xml blah blah blah… pero la verdad es que toda esta información ya está escrita y está en la interfaz del EJB. La pregunta es como hacemos para transformar este código en información visible, y no voy a dar mas vueltas.

Si le damos una repasada a las instancias de la clase java.lang.Class vemos que cuenta los siguientes metodos ( ademas de unos cuantos más ) :

• public Method[] getMethods();
• public Field[] getFields();
• public Constructor[] getConstructors();
• public Annotation[] getAnnotations();

Con este grupo de métodos podemos sacar mucha información sobre una instancia ( sobre la clase de una instancia ) tanto sea un EJBs, un POJO o lo que sea.

Method[] ms = instancia.getClass().getMethods();
System.out.println("metodos de la clase " + instancia.getClass().getName() );
for(Method m : ms ){
    System.out.println("    nombre: " + m.getName() );
}

Esto es básico, si ahora queremos llamar a un metodo que eligió el usuario después de que le mostramos las opciones:

// obtenemos la referencia al metodo
method = obtenerElMetodoPorElNombre( opcion );
// y lo invocamos
method.invoke( instancia, parametro1, parametro2 );
// ó con un array de parametros
method.invoke( instancia, new Object[]{ parametro1, parametro2 } );

Excelente no? Esto sigue siendo magia para gnomos de clase baja… veamos ahora a algo mas complejo: Proxies.

Los proxies son instancias de ninguna clase

(??) Como es esto? Si no tiene una clase asociada como la instanciamos? Que métodos tiene asociado? Para eso antes tienen que saber que es un InvocationHandler ( “manejador de invocaciones” a métodos  ).

Un IH es una interfaz que nos va a permitir asociar un objeto a esta instancia mágica sin clase asociada, el proxy. Una ves que tenemos una instancia de un IH, creamos el proxy y le decimos que él será el encargado de recibir las invocaciones a los métodos que el proxy no pueda resolver, porque el proxy no tiene definición de clase por lo tanto no tiene un conjunto de métodos definidos ni implementados. Vamos a las fuentes:

Creemos nuestro IH:

public class ManejadorDeInvocaciones implements InvocationHandler {
    private String texto;
    public ManejadorDeInvocaciones(String texto){
        this.texto = texto;
    }
    // el unico metodo para implementar segun la interfaz
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        System.out.println(texto + metodo.getName() );
        return true; // solo para que funcione el ejemplo siguiente
    }

}

Ahora creemos nuestro proxy mágico y asociemosle el IH. Para eso llamamos al método newInstance con tres parametros en el siguiente orden:

• classloader : Como hay que crear la definición de una clase al vuelo, esta clase tiene que estar asociada a un classloader que por lo general es this.getClass().getClassLoader()
• interfaces: la lista de interfaces que esta clase imaginaria implementa esto nos permite castear el proxy a cualquiera de estas interfaces y utilizarlo como si fuera una instancia de dicha interfaz, transparente para el usuario. Puede ser una lista vacía.
• invocationHandler: nuestra instancia de IH que queremos que se encargue de recibir los llamados a los métodos de esta instancia proxy 

   Object unProxy = Proxy.newProxyInstance( this.getClass().getClassLoader() , new Class[]{ java.util.List.class }, new ManejadorDeInvocaciones("llamando al metodo ") );

Ahora, cualquier método que invoquemos a unProxy automáticamente invocará al método “invoke” del IH con la referencia al proxy, método y los argumentos correspondientes. Genial no? Pero si es un Object no podemos llamar a muchos métodos… para eso está el segundo parámetro, para poder castear nuestro proxy a alguna interfaz de nuestra elección. Por lo tanto lo siguiente es válido:

    List lista = (List) unProxy;
    ....
    lista.add( new Integer(4) );

Un detalle, tener en cuenta que el método de la interfaz en si limita un poco la respuesta del método invoke. Por ejemplo, en este caso si el IH devuelve null para la llamada al método boolean add( Object o ) vamos a recibir un lindo NullPointerException con toda razón.

Si para esta altura no se aburrieron de leer ( yo no me aburrí de escribir :P ) les voy a enseñar un truco mas con todo lo aprendido. 

Supongamos que queremos una lista que guarda números, pero solo números pares … (??) si un ejemplo bien básico :D Como harían esto? Sabemos que podemos filtar el tipo con List<Integer> pero no podemos filtrar los valores, para eso tendríamos que extender de ArrayList y reimplementar el método add para agregarle esta loca validación que se me acaba de ocurrir. Otra es hacer un proxy y usarlo como filtro, así:

    // definimos el filtro
    public class ManejadorDeInvocaciones implements InvocationHandler {
        private List<integer> target;
        public ManejadorDeInvocaciones(List</integer><integer> target){
            this.target = target;
        }
        // el unico metodo para implementar segun la interfaz
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            if ( method.getName().equals("add") ){
                Integer i = (Integer)args[0];
                if (i % 2 == 1) return true;
            }
            return method.invoke( target , args);
        }
    }
    //la lista que tendra los numeros
    List</integer><integer> lista = new ArrayList();

    //le asociamos el filtro
    lista = (List</integer><integer>)Proxy.newProxyInstance( this.getClass().getClassLoader() , new Class[]{ List.class }, new ManejadorDeInvocaciones(lista) );

    //trabajamos como si fuera una lista comun y corriente
    lista.add( new Integer(5) );
    lista.add( new Integer(2) );

Algo para destacar muy importante es el código del filtro queda completamente separado de la instancia _objetivo_, como vemos la definición de la lista ( List ) no conoce el filtro, la implementación de la lista ( ArrayList ) tampoco y ni siquiera el cliente, el usuario de la lista, porque no afecta para nada la manera en la que trabajamos con la lista.  Así como agregamos un filtro de números pares podemos agregar un filtro para transaccionabilidad, un filtro para seguridad con JAAS,  control de concurrencia pero si hacemos todo eso estaríamos haciendo algo muy parecido a lo que hizo JBoss para implementar el stack de EJB 3.0. Eso lo dejo para otro post.

La frutilla del postre viene ahora, con algo que encontré revisando las librerías que vienen con la jdk.

Resulta que cuando queremos llamar a un método usando reflection hay que tener cuidado al buscar la referencia al método que queremos llamar, ya que cuando utilizamos el método java.lang.Class.getMethod(String name, Class… paramTypes) la busqueda es explicita. Me refiero a que si buscamos el método X que resolvería la jvm para satisfacer Z cantidad de parámetros tenemos que simular la búsqueda del método según las superclases de los tipos de parámetros!!! Suena complicado, y lo es. Suena a que debería estar echo, y lo está… pero está oculto.   

Explicación “grafica” :

assert List.class.getMethod("add", Object.class) != null; // esta invocacion devuelve el metodo add
assert List.class.getMethod("add", Integer.class) != null; // esto tira la excepcion java.lang.NoSuchMethodException

Y tiene sentido, porque aunque cuando llamemos a java.util.List.add( Integer ) sepa a cual nos referimos, el método add( Integer ) no existe. 

Para hacer esto podemos mirar pero no usar ( si escucharon leyeron bien ) la clase java.beans.ReflectionUtils del recurso classes.jar, que no tiene javadoc pero tiene una muy linda explicación en la cabecera:

/**
 * A utility class for reflectively finding methods, constuctors and fields
 * using reflection.
*/

Al parecer es una clase protegida y solo puede ser invocada si estamos desde el mismo paquete, así que lo que yo aconsejo es copiar y pegar todo el código fuente =D total… no cambia a menos que corran en otra jdk. ( tener cuidado de eso )

De este “grupo de funciones” podemos usar Method getPublicMethod(Class declaringClass, String methodName, Class[] argClasses) para encontrar un método que satisfaga los tipo de parámetros que le estamos pasando. Si ven el código fuente se van a dar cuenta que es mucho mas complicado de lo que pensaron jeje.

Bueno eso es todo lo que tengo para decir por el momento de reflection, esto sirve como base para el próximo post sobre un custom interceptor de Seam para hacer algunas cosas locas y para un patrón dinamico de DTO que hice hace mucho, capas le sirve a alguno. Hasta entonces.

Una de ellas es tener un mirror del blog en inglés, también en wordpresss.

Y otra es que me envicié portando la implementación de Sun de JSF para J2SE =D . See, hay una nueva moda, cuestionar JEE y preguntar porque estas funcionalidades no lo puedo tener en mis aplicaciones. Esto empezó con Context and Dependecy Injection for Java ( aka jsr-299 ( aka WebBeans ) ) que con mucha lógica dijeron “Gavin, ¿Qué tiene que ver contextos y DI con JSF y EJB?” o algo similar, ahora me toca a mi seguir con la moda.

Me hice la pregunta ( hace tiempo ya, pero no tengo pruebas =P ) ¿Por qué no puedo utilizar las ventajas de la programación declarativa en mis aplicaciones desktops y dejar de romperme la cabeza ( aka marote ) en pensar si voy a usar Swing, SWT o similares? Por cierto para tener en cuenta, parece que Sun bajó los brazos en este area.

Y el proyecto está avanzando, ayer casi logro levantar un ejemplo pero el spec de JSF parece estar muy ligado al paquete javax.servlet.http y voy a tener que hacer un poco de magia negra, pero de la buena. En cuanto tenga un ejemplo se los muestro, la idea es definir las vistas con JSF/Facelets y implementar un RenderKit para dibujar con la tecnología que queramos. Una vez superado eso agregar Seam, aunque sería óptimo tener una versión GA de OWB ó WB para entonces.

Salut

qué es Seam?

Antes de escuchar de mis palabras que es Seam, veamos un poco que dice el sitio oficial.( con mis comentarios )

“Seam is a powerful open source development platform…” ( de lo que solo se desprende que es una plataforma =D )

“Seam integrates technologies such as …. “ ( integra tecnologías )

“… has been designed from the ground up to eliminate complexity at both architecture and API levels.”

Si vamos al doc oficial, en la introducción nos cuentan que:

• [Seam is] One kind of “stuff” ( no nos dice mucho )
• Integrate JSF with EJB 3.0 ( integración de tecnologías )
• Integrated AJAX ( integración de tecnologías )
• Business process as a first class construct ( integración de tecnologías )
• Declarative state management ( programación declarativa utilizando meta-información )
• Bijection ( motor de dependency injection ( … que sirve para integrar ) )
• Workspace management and multi-window browsing ( producto del nuevo manejo de contextos )
• Prefer annotations to XML ( marketing )
• Integration testing is easy ( … marketing )
• y un par de cosas mas…

Entonces, de esto se desprenden algunas ( no todas ) de las características mas importantes: la habilidad de integrar tecnologías de diferentes ámbitos a través de la inyección de dependencias. A eso se le agrega un trabajo mas fino de los contextos, tenemos mas contextos lo que no quiere decir que ocupemos más memoria, si no que todo lo contrario vamos a tener más opciones para elegir donde guardar nuestras instancias y estas van a permanecer en memoria el tiempo indicado. Y por último Seam en ingles significa costura, los que nos da una idea de integración también, si bien una prenda de vestir no está echa solo de costuras ( la tela con la que está echa es mucho mas importante ) forma una parte importante.

En mi trabajo me pidieron que describiera JBoss Seam para un cliente que no está seguro de querer utilizar dicha tecnología, mi respuesta fue:

“JBoss Seam es una plataforma de integración de tecnologías que tiene como objetivo facilitar el desarrollo de aplicaciones JEE ( sobre todo aplicaciones web ). Es un proyecto Open Source con una comunidad abierta y aunque cuenta con el respaldo de JBoss, su funcionalidad no está ligada al servidor de aplicaciones de este. El desarrollo de Seam, utilizando JSF y EJB que son las tecnologías con mas soporte, es muy ágil ya que reduce el nivel de configuración necesario para la integración y aprovecha al máximo las ventajas de cada una de las tecnologías haciendo al proyecto mas estable, legible, predecible y mantenible.  

Con esto ya deben tener una visión macro de lo que es el producto. Para entrar mas en detalle necesitaría un par de hojas mas y mas tinta porque es bastante extenso, pero les puedo recomendar un libro muy bueno que me ayudo en mis comienzos.

cómo se relaciona Seam con el jsr-299?

Como recién mencioné, Seam junto a Google Guice y Spring, impulsaron la necesidad de ponerse de acuerdo en la manera de como Java utilizaba Dependency Injection, definir el nuevo concepto de ciclo de vida de los “beans” y normalizar los contextos asociados… sobre todo el revolucionario contexto conversacional. Hicieron un muy buen trabajo por cierto.

Seam cumplirá con el jsr-299?

Por supuesto, va a ser la novedad de la tercera versión de Seam y va a estar disponible para JBoss 5 ( aunque seguramente allá algunos hacks para entonces ;) ). Como no sigo los proyectos de Guice y Spring no se que será de estos frameworks, pero no será distinta la postura.

Algunos comentarios mas al respecto:

• JBoss y Apache ya tienen una implementación de referencia de Contexto and Dependency Injection (aka jsr-299) en un  estado entre alpha y beta… radioactivo ( busquen en mis post )
• Wicket no tiene nada que ver con la especificación, como JSF
• Mas sobre jsr-299 en el próximo posts =)

Saludos

Fuentes:

• Entrevista a Gavin King
• Documentacion del jsr-299

Lo que no esperaba encontrarme es que ambos tengan diferencias en los fuentes de la interfaces, y no me refiero a la implementación lo cual es completamente entendible, pero si no nos ponemos de acuerdo en las interfaces de entrada… stamo fritos stamo.

Importante, tener en cuenta las versiones que tomé como referencia:

• De la implementación de referencia ( RI ) de Pete Muir utilicé la version 1.0.0.BETA1 ya que es la última que cerraron
• De la RI de Gurkan Erdogdu tomé la última revisión trunk del SVN público al día de la fecha

Pero ¿Qué tipo de diferencias podemos llegar a tener en las interfaces, clases y anotaciones ( teniendo un documento q regule esto ) que influyan en el comportamiento? Hasta ayer me animaba a decir ninguna, pero no es este el caso. Veamos las diferencias:

*Nota: Cuando quiera referirme a la diferencia de códigos voy a utilizar “gurkan” para el código de de OpenWebBeans y “pete” para el código de WebBeans.

En las clases

Es lo mas difícil de analizar, ya que no solo tienen que mantener el mismo contrato público ( nombre de métodos, cantidad y tipo de parámetros ) si no que su implementación, sin necesidad de tener las mismas lineas de código debe tener el mismo resultado. Por suerte, solo tenemos dos clases y son fácil de analizar :D.

javax.inject.AnnotationLiteral

Esta clase ayuda a representar una anotación en forma de una instancia para poder usarla como parámetro de un inyección manual de un componente.

public boolean equals(Object other)

gurkan – tiene mejores validaciones
pete – posible NullPointerException en linea 141 cuando el método de una anotación devuelva un valor nulo.

Pasemos ahora por las las interfaces, en realidad clases abstractas y interfaces 

 javax.inject.manager.Bean

No estoy seguro, pero creo que esta diferencia puede traer problemas de compatibilidad ( compilar con una y utilizar otra en tiempo de ejecución ) y según lo que dice el capitulo 3.11 en la página 39 ( jeje paresco un abogado ) la versión de Gurkan tiene la razón.

pete – public abstract Set<? extends InjectionPoint> getInjectionPoints();
gurkan – public abstract Set<InjectionPoint> getInjectionPoints();

javax.inject.manager.Decorator

Acá hay un problema grave, los nombres de los métodos no concuerdan. Y según la documentación, específicamente en la página 113 de jsr-299 dice que Pete tiene razón.

pete – public abstract Set<Annotation> getDelegateBindings();
gurkan – public abstract Set<Annotation> getDelegateBindingTypes();

javax.inject.manager.Manager

La verdad no se que diferencias puede traer, pero ya que estamos la nombramos. Si alguien sabe, que me lo explique. 

pete – public <T> T getInstanceToInject(InjectionPoint injectionPoint, CreationalContext<?> creationalContext);
gurkan – public <T> T getInstanceToInject(InjectionPoint injectionPoint, CreationalContext<T> context);

Y por último, pero no memos importante, las anotaciones:

javax.annotation.Named

pete – @Target( { TYPE, METHOD, FIELD })
gurkan – @Target( { TYPE, METHOD })

javax.webbeans.Model

gurkan - @Production
gurkan - @Documented
gurkan - @Inherited

javax.interceptor.Interceptor

gurkan - @Inherited

javax.context.ApplicationScoped

pete – @Target( { TYPE, METHOD, FIELD })
gurkan - @Target( { TYPE, METHOD })

javax.context.ConversationScoped

pete – @Target( { TYPE, METHOD, FIELD })
pete – @Documentend
gurkan - @Target( { TYPE, METHOD })

javax.decorator.Decorator

gurkan - @Inherited

 javax.event.Asynchronously

pete – @Documented

javax.inject.Disposes

gurkan - @Documented

javax.inject.New

pete – @Target( { FIELD, PARAMETER })
gurkan - @Target( { METHOD, FIELD, PARAMETER })

javax.inject.Production

pete – @Target( { TYPE, METHOD, FIELD })
gurkan - @Target( { TYPE, METHOD })

javax.inject.Standard

pete – @Target( { TYPE, METHOD, FIELD })
gurkan - @Target( { TYPE, METHOD })

Fuentes

• Versión 1.0.0.BETA de WebBeans desde svn 
• Revisión 764218 de OpenWebBeans desde svn
• Jsr-299 versión actualizada desde el sitio oficial

Navegando por la web encontré que Gurkan Erdogdu viene trabajando este tema desde hace rato en su blog y hasta tiene su propia implementación: OpenWebBeans

Habrá que seguirla de cerca para ver como evoluciona, groso.

P.D.: Al parecer tiene otro blog

Salut

• Dependency Injection and Contexto for Java (aka WebBeans)
• Stress testing en aplicaciones web utilizando  Seam ( JSF, EJB, Seam )
• DynamicDTO, un mini proyecto abandonado que revive desde lo obscuro
• JBoss 5 y OSGi
• Seam en general

Quizás me olvide de algo, pero mas o menos es eso y hasta con ese orden de importancia.

Así que ya saben, por si estos temas no les interesa/gustan los temas ;)

Salut

Un patrón muy utilizado dentro del mundo JEE es el conocido Service Locator, sobre todo para acceder a instancias de EJBs como vamos a ver en el ejemplo mas adelante.

Lamentablemente, aunque se detecta la necesidad de un componente que resuelva el problema de acceder ciertos servicios no siempre la solución implementada cumple con los requisitos o la manera de resolverlo tiene resultados no esperados, como por ejemplo hacer que dicho patrón sea estático o mezclarlo con un Singleton y sumar al caldo un cache _global_ de Stateful Session Bean (aka SFSB), aunque irónicamente se haga cache de Stateless Session Bean (aka SLSB) con el mismo fin. Está bien, en ciertas ocasiones un cache no vendría mal pero vale la pena analizarlo a fondo porque, como _toda_ solución de cache ( deberían anotarlo si no lo saben ), trae muchos efectos colaterales… muchos.

Primer problema, supongamos que decidimos hacer a la instancia del Service Locator (desde ahora SL) estática porque observamos que no importa el estado del SL, para un nombre de SB queremos que nos devuelva dicho SB sea SF o SL. Si la instancia del Service Locator es única los SFSB que quedan asociados van a ser los mismos para cada llamado dentro de la aplicación, haciendo a nuestro SFSB un servicio estático también.

Segundo problema, si la referencia que tenemos a cada SFSB se mantienen abierta durante mas tiempo de lo que necesitamos y tenemos un problema de conexión o cualquier otro imprevisto ya no hay manera de volver a usar dicho servicio si no renovamos la referencia, esto va sobretodo para aquellos que usan los SFSB con “métodos estáticos” o sin estados como por ejemplo “int sumarDos(int base)”. Para que se entienda, si tenemos un SFSB asociado a la sesión y el servidor de EJBs se reinicia entro dos llamados, el segundo llamado va a fallar porque el id de SFSB que tiene el cliente que consume dicho servicio no existe en el servidor de EJBs, tirando la siguiente excepción:

javax.ejb.NoSuchEJBException: Could not find stateful bean: <super_id_largo_y_horrible>

Los problemas, o mejor dicho las causas de perder la referencia a un SFSB pueden ser varias ( no siempre un problema ), las mas comunes:

• Reinicio del servidor de EJBs, si tenemos el cliente y los ejbs en diferentes máquinas virtuales
• Inactividad por un tiempo prolongado. Recuerden que los SFSB son uno por cliente, por lo que el contenedor de EJBs destruirá cualquier SFSB que esté inactivo por mas tiempo que por configuración se le indica.
• Si llamamos a un método con la anotación @javax.ejb.Remove pero mantenemos la referencia al SFSB.
• etc..

Solución: NO guardar ninguna instancia de Session Bean en un Service Locator, por mas tentadora que parezca la idea, por mas creamos que sea una buena optimización. En el único caso que vale la pena es cuando sabemos que vamos a consumir solo SLSB, pero como el cliente supuestamente no sabe nada sobre la implementación de los servicios esta solución nos puede traer mas dolores de cabeza mas tarde.

Dicho esto y como el titulo prometía hablar de JBoss Seam vamos a ver que les parece mi propuesta. Mi Service Locator, si bien van a ver que las clases tienen dependencias de runtime en Seam, la idea principal se puede usar sin este framework.

Empecemos por el principio, el punto de vista del usuario del patrón. ¿Cuál es el mejor Service Locator que conocen? Yo el @EJB, vamos a ver que tan parecido lo podemos hacer.

Hay una anotación de Seam muy parecida, @org.jboss.seam.annotations.In que nos permite inyectar dependencias, el problema es que no queremos hacer un componente diferente por cada implementación que valla a utilizar el cliente, a lo sumo llamaremos al SL con el nombre del EJB que queremos utilizar. Y como hacemos eso con Expression Language (EL) ? Un mapa de ejbs :D

Sería algo como esto:

    @org.jboss.seam.annotations.In("#{locator['myEJBImplBean']}")
    private MyEjbInterface mei;

Excelente, entonces _locator_ es nuestro componente encargado de encontrar los servicios, nuestro Service Locator. Pero como que es un Mapa? Veamos la implementacion

@Name("locator")
@Scope(ScopeType.APPLICATION)
public class EjbLocator implements Serializable {

    public Object locate(String name) throws RuntimeException {
        try {
            String jndi = Init.instance().getJndiPattern();
            return new InitialContext().lookup( jndi.replace("#{ejbName}", name) );
        } catch (NamingException ex) {
            log.error("Error inicializando el ejb " + name , ex);
        }
        return null;
    }

    @Unwrap
    public Map<string ,Object> getResource(){
        return new Map</string><string ,Object>(){

            public Object get(Object key) {
                return locate((String)key);
            }

            /* .... muchos metodos que no tiene sentido agregar ... */

            public Object put(String key, Object value) {
                throw new UnsupportedOperationException("Not supported yet.");
            }

        };
    }

}

Nota:

• Todas las anotaciones están bajo el paquete org.jboss.seam.annotations
• La instancia de InitialContext se podría generar menos seguido
• Obviamente quite código q no venia al caso :)

Entonces, tenemos un componente Singleton que nos sirve como Service Locator que cuando hacemos referencia a él lo que obtenemos es un mapa. Cuando busquemos un objeto dentro del mapa con la key X, el SL intentará encontrar una referencia a un EJB con el nombre X.

Claramente, los métodos pueden ser estáticos pero la verdad en este caso no hace la diferencia, la magia está en como esto se mezcla con Dependency Injection y Expression Language. Sientanse libres de mandar sugerencias, ideas, correcciones o simples comentarios.

Y como decían en Nivel-X, bueeeno.. esto fue todo y espero q les haya gustado. ( espero que no tenga copyright =P )

Y.. lo primero es lo primero, como va a ser una bitácora de lo que me valla surgiendo en la mente que tenga que ver java principalmente ya estuve averiguando algo importante… como postear código java y diferenciarlo del texto de entrada común y silvestre. No fue complicado, algunos queries mágicos al motor de búsqueda por defecto y encontramos algo bastante bueno.

Un ejemplo:  

   public class PrimerPost {
      public static void main (String args[]) {
         System.out.println ("wordpress rulz!");
      }
   }

Salut

Fuente:

• wordpress support