Skip navigation

Monthly Archives: abril 2009

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

Como había comentado en el anterior post, mas de un grupo está trabajando en una implementación de Java Context and Dependency Injection ( aka jsr-299 ) por un lado lo tenemos al grupo de Apache con Gurkan Erdogdu a la cabeza y por otro al grupo de JBoss con Pete Muir.

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.

Seguir leyendo

Una buena noticia para mi, una muy buena para todos los que seguimos de cerca la JSR-299 y que solo conocían de la implementación del equipo de JBoss de esta especificación.

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

Para no perder el camino/idea del blog y para darle un poco mas de forma a esto que crece ( tampoco para que me sirva de machete =D ) voy a hacer un resumen de los  temas quiero tratar acá:

  • 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 )

Primer post de sebasjm en wordpress… vamos a ver que sale de esto. Parece mucho mas potente que mi anterior blog, aunque a ese no lo empecé con tantas ganas.

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 (&quot;wordpress rulz!&quot;);
      }
   }

Salut

Fuente: