Skip navigation

Tag Archives: seam

El próximo 21 estaré dando una charla sobre desarrollo web usando herramientas de JBoss.

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.

Increíble que haya que dar tantas vueltas para algo tan simple. El problema radica en que no hay manera de terminar una conversación “manualmente” sumando a que cada request dispara crea una nueva conversación.

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.

Seguir leyendo y viendo las imágenes

Construido por usuarios y desarrolladores de proyectos de la comunidad JBoss y dedicado para cada uno de los miembros de la comunidad. 

He aquí… con ustedes… les presento…

Desplegar cortinas

Buenas, habrán notado que tuve un pico de blogs y ahora bajo un poco… no crean que esto va a terminar tan rápido. Simplemente estuve trabajando en algunas cosillas que por supuesto tienen que ver con esta bitácora. 

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

Buenas, ya más de una vez me preguntaron y varias veces escuche definiciones no del todo exactas acerca de…

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…

Seguir leyendo

 

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 )