Tecnologías Java

Charla: Desarollo de Aplicaciones JavaEE 5 con Productos JBoss

2011-04-21T10:39:00.000-07:00

Epidata Consulting los invita a participar de la charla "Desarrollo de aplicaciones JavaEE 5 con productos JBoss", que tendrá lugar el próximo miércoles 4 de mayo, de 18.30 a 20.30hs en la Facultad de Ingeniería de la UBA (FIUBA), sita en Paseo Colón 850.

La actividad tendrá como objetivo presentar la arquitectura de una aplicación JavaEE tipo y mostrar cuáles son algunos de los componentes, especificaciones y tecnologías que se suelen utilizar en cada capa. Puntualmente, al hablar de especificaciones se hará hincapié en JavaEE 5 y en cuanto a implementaciones el foco estará puesto en productos de desarrollo de JBoss. La charla será dictada por Adrián Paredes, arquitecto de software de Epidata Consulting.

La charla está dirigida a Desarrolladores Java y a Programadores interesados en esta tecnología, y será de índole conceptual e introductoria.

Orador

Ing. Adrián Paredes

Adrián Paredes es Ingeniero en Informática (FIUBA) y se desempeña como arquitecto de software y desarrollador en Epidata Consulting. Cuenta con 3 años de experiencia en proyectos JavaEE. Actualmente se encuentra trabajando en un proyecto de migración de aplicaciones internas de Swiss Medical, como partner de Red Hat, utilizando la SOA Platform de JBoss y Seam para las aplicaciones web.

Detalles

Miércoles 4 de mayo de 2011

18.30 a 20.30 hs

Facultad de Ingeniería de la UBA

Paseo Colón 850, Salón del consejo

Capacitación gratuita y abierta al público

Inscripciones: http://bit.ly/e4Bwhl

Vía: http://www.epidataconsulting.com/site/pages/noticia/Desarrollo-de-aplicaciones-JEE5-con-JBoss

JSON (JavaScript Object Notation)

2010-02-01T04:47:00.000-08:00

JSON (JavaScript Object Notation) es un formato ligero para el intercambio de datos. Es un subconjunto de la notación literal de objetos de JavaScript. JSON es sencillo de escribir, sencillo de leer, sencillo de manipular, y en la mayoría de los casos es mucho más liviano que XML.

JSON maneja dos estructuras básicas:

Colección de pares nombre/valor, conocidas en varios lenguajes como Objetos, Registros, Estructuras, Diccionarios, Mapas, Arrays Asociativos
Lista ordenada de valores, conocidas en varios lenguajes como Arrays, Vectores, Listas, Secuencias

Para facilitar la comprensión, llamaremos a las primeras Mapas u Objetos, indistintamente, y a las segundas Listas o Arrays. En Java los Mapas se pueden corresponder con instancias concretas de la clase java.util.Map o con simples Java Beans (objetos Java sin métodos y con setters y getters para cada uno de los atributos). A la vez, las Listas se pueden asociar con instancias concretas de la clase java.util.List o meros Arrays que mantienen ordenados sus elementos.

En la notación JSON los Mapas comienzan con llave de apertura "{" y terminan con llave de cierre "}". Tanto los Mapas como las Listas son colecciones de elementos. En el primer caso los elementos son pares nombre/valor; en el segundo, solamente valores. Los dos elementos de un par (nombre y valor) están separados por dos puntos ":" y los nombres, o claves para seguir con la terminología de Mapas, siempre tienen que ser del tipo String.

Las Listas comienzan con corchete de apertura "[" y terminan con corchete de cierre "]" y sus elementos, como mencioné antes, están separados por comas ",".

Por último, los valores pueden ser del tipo string, number, object (Mapa), array (Lista), booleano (true/false) o null.

Veamos algunos ejemplos.

Definamos la clase Persona con sus atributos "nombre", "apellido", "fechaNacimiento", "soltero", "cantHijos":

public class Persona {

   private String nombre; 

   private String apellido;  

   private Date fechaNacimiento;  

   private Boolean soltero;  

   private Integer cantHijos;

   // ... Los setters y getters para cada atributo ...
}

Carguemos un objeto Persona:

   Persona persona = new Persona();
   persona.setNombre("Adrian");
   persona.setApellido("Paredes");     
   persona.setFechaNacimiento(parseDate("03/06/82", "dd/MM/yy"));
   persona.setSoltero(false);
   persona.setCantHijos(0);

Una forma equivalente de guardar este objeto sería en un HashMap:

   Map persona = new HashMap();
   persona.put("nombre", "Adrian");
   persona.put("apellido", "Paredes");
   persona.put("fechaNacimiento", parseDate("03/06/82", "dd/MM/yy"));
   persona.put("soltero", false);
   persona.put("cantHijos", 0);

Dejemos de lado por un momento el campo "fechaNacimiento" y veamos cómo se representaría este Mapa en formato JSON, repito: sin la fecha de nacimiento:

{
   "nombre" : "Adrian",
   "apellido" : "Paredes",
   "cantHijos" : 0,
   "soltero" : false
}

Ahora agreguemos el atributo "fechaNacimiento":

{
   "nombre" : "Adrian",
   "apellido" : "Paredes",
   "cantHijos" : 0,
   "soltero" : false,
   "fechaNacimiento" : {
       "year" : 82
       "month" : 5,
       "day" : 4,
       "date" : 3,
       "hours" : 0,
       "minutes" : 0,
       "seconds" : 0,
       "time" : 391921200000,
       "timezoneOffset" : 180,
   }
}

El atributo "fechaNacimiento" es del tipo java.util.Date, por lo tanto, lo que estamos viendo en el JSON es un Mapa dentro del Mapa principal que es Persona. Los campos "year", "month", "day", "date", "hours", "minutes", "seconds", "time" y "timezoneOffset" son los atributos de la clase java.util.Date.

Hay algunas bibliotecas de JSON que serializan los objetos java.util.Date de formas más compacta. Estas formas escapan al estándar de JSON. Por ejemplo, jabsorb, un broker que sirve como framework liviano para aplicaciones Ajax/Web 2.0, escribiría el JSON de Persona de esta manera:

{
   "nombre" : "Adrian",
   "apellido" : "Paredes",
   "cantHijos" : 0,
   "soltero" : false,
   "fechaNacimiento" : {
       "javaClass" : "java.util.Date",
       "time" : 391921200000
   }
}

Como jabsorb es un broker diseñado para transportar datos a tavés de una red, esta forma de serializar los objetos Date es beneficiosa, ya que suprime la información redundante.

Para hacer un poco más interesante esta introducción a JSON, vamos a agregarle dos atributos a la clase Persona:

   private Direccion direccion;

   private List nombreHijos;

   // Y agregamos los setters y getters...

La clase Direccion está definida de esta forma:

public class Direccion {

   private String calle;

   private Integer numero;

   // ... Los setters y getters para cada atributo ...
}

Supongamos que la Persona "Adrián Paredes" esta vez sí tiene hijos y tiene tres: "Marco", "Polo" y "Lolita":

   Persona persona = new Persona();
   persona.setNombre("Adrian");
   persona.setApellido("Paredes");     
   persona.setFechaNacimiento(parseDate("03/06/82", "dd/MM/yy"));
   persona.setSoltero(false);
   persona.setCantHijos(3);
  
   List nombres = new ArrayList();
   nombres.add("Marco");
   nombres.add("Polo");
   nombres.add("Lolita");
   persona.setNombreHijos(nombres);
  
   Direccion direccion = new Direccion();
   direccion.setCalle("Av. Siempre Viva");
   direccion.setNumero(2012);
   persona.setDireccion(direccion);

Lo que en el lenguaje de Mapas y Listas sería:

   Map persona = new HashMap();
   persona.put("nombre", "Adrian");
   persona.put("apellido", "Paredes");
   persona.put("fechaNacimiento", parseDate("03/06/82", "dd/MM/yy"));
   persona.put("soltero", false);
   persona.put("cantHijos", 3);
  
   List nombres = new ArrayList();
   nombres.add("Marco");
   nombres.add("Polo");
   nombres.add("Lolita");
   persona.put("nombreHijos", nombres);
  
   Map direccion = new HashMap();
   direccion.put("calle", "Av. Siempre Viva");
   direccion.put("numero", 2012);
   persona.put("direccion", direccion);

Serializado a JSON este objeto quedaría:

{
   "nombre" : "Adrian",
   "apellido" : "Paredes",
   "fechaNacimiento" : {
       "year" : 82
       "month" : 5,
       "day" : 4,
       "date" : 3,
       "hours" : 0,
       "minutes" : 0,
       "seconds" : 0,
       "time" : 391921200000,
       "timezoneOffset" : 180,
   },
   "cantHijos" : 3,
   "nombreHijos" : ["Marco", "Polo", "Lolita"],
   "soltero" : false,
   "direccion" : {
       "calle" : "Av. Siempre Viva",
       "numero" : 2012
   }
}

JSONLint (Validador de JSON)

JSONLint es un validador de JSON on-line. Muy útil para cuando queremos verificar si un JSON está bien formado o no. Cuando un JSON es muy grande, la población de llaves y corchetes puede crecer bastante. Si nos olvidamos algún corchete de cierre, alguna llave de apertura, algunas comillas, JSONLint nos indicará en qué línea está el problema, simplemente copiando y pegando la cadena JSON y presionando el botón Validate.

JSON-lib

Lo más práctico de JSON es que es muy fácil de parsear. Al final de la página oficial de JSON hay una lista de bibliotecas útiles para usar en distintos lenguajes (Java, C#, Delphi, Lisp, Phyton, Ruby, etc). Siendo Java tan popular, hay muchas herramientas que sirven para este lenguaje. Una de ellas es JSON-lib.

JSON-lib es una poderosa biblioteca que permite transformar Java Beans, Mapas, Colecciones, Arrays y XML a JSON y viceversa. Hasta convierte de JSON a DynaBeans de Apache Commons, si no necesitamos crear una clase. También soporta algunas funcionalidades que no entran dentro del estándar como la serialización y deserialización de funciones JavaScript.

Usar esta librería es muy fácil. Si estás usando Maven2, la dependencia a incluir es:

<dependency>
    <groupId>net.sf.json-lib</groupId>
    <artifactId>json-lib</artifactId>
    <version>2.3</version>
    <classifier>jdk15</classifier>
<dependency>

Sino, debes incluir en el classpath estas librerías:

jakarta commons-lang 2.4
jakarta commons-beanutils 1.7.0
jakarta commons-collections 3.2
jakarta commons-logging 1.1.1
ezmorph 1.0.6

Además del mismo jar de JSON-lib, por supuesto.

A la hora de parsear una cadena JSON, JSON-lib lo que hace es almacenar los Objetos y los Arrays en Mapas y Listas. Un objeto JSON es volcado en una instancia de la clase JSONObject y un array JSON a una instancia de la clase JSONArray. Ambas clases implementan las interfaces java.util.Map y java.util.List respectivamente.

Pasar de Java Bean, Mapa o Lista a JSONObject es casi trivial. Simplemente usamos el método estático de fromObject de JSONObject o JSONArray según corresponda.

Por ejemplo, si queremos pasar un objeto Persona a JSON:

   Persona persona = new Persona();
   persona.setNombre("Adrian");
   persona.setApellido("Paredes");
   persona.setFechaNacimiento(parseDate("03/06/82", "dd/MM/yy"));
   persona.setSoltero(false);
   persona.setCantHijos(3);
  
   List nombres = new ArrayList();
   nombres.add("Marco");
   nombres.add("Polo");
   nombres.add("Lolita");
   persona.setNombreHijos(nombres);
  
   Direccion direccion = new Direccion();
   direccion.setCalle("Av. Siempre Viva");
   direccion.setNumero(2012);
   persona.setDireccion(direccion);

   JSONObject jsonObj = JSONObject.fromObject(persona);
   System.out.println(jsonObj);

La salida del System.out.println de este código va a ser sencillamente el string JSON:

{
   "nombre" : "Adrian",
   "apellido" : "Paredes",
   "fechaNacimiento" : {
       "year" : 82
       "month" : 5,
       "day" : 4,
       "date" : 3,
       "hours" : 0,
       "minutes" : 0,
       "seconds" : 0,
       "time" : 391921200000,
       "timezoneOffset" : 180,
   },
   "cantHijos" : 3,
   "nombreHijos" : ["Marco", "Polo", "Lolita"],
   "soltero" : false,
   "direccion" : {
       "calle" : "Av. Siempre Viva",
       "numero" : 2012
   }
}

Esto es así, ya que el objeto JSONObject tiene sobrecargado el toString() para que escupa el mapa en formato JSON. Así de sencillo.

Si queremos pasar de HashMap a JSON, el código es exactamente igual:

   Map persona = new HashMap();
   persona.put("nombre", "Adrian");
   persona.put("apellido", "Paredes");
   persona.put("fechaNacimiento", parseDate("03/06/82", "dd/MM/yy"));
   persona.put("soltero", false);
   persona.put("cantHijos", 3);
  
   List nombres = new ArrayList();
   nombres.add("Marco");
   nombres.add("Polo");
   nombres.add("Lolita");
   persona.put("nombreHijos", nombres);
  
   Map direccion = new HashMap();
   direccion.put("calle", "Av. Siempre Viva");
   direccion.put("numero", 2012);
   persona.put("direccion", direccion);

   JSONObject jsonObj = JSONObject.fromObject(persona);
   System.out.println(jsonObj);

El fromObject puede recibir prácticamente cualquier cosa. Ya vimos que podemos mandarle un Bean y un HashMap, cualquier cosa que pueda convertirse en Mapa de JSON. Por supuesto, también puede recibir un String JSON. De esta forma, podemos deserealizar objetos:

String jsonStringPersona = "{" +
       "\"apellido\":\"Paredes\"," +         
       "\"nombre\":\"Adrian\"," +         
       "\"direccion\":{" +         
           "\"calle\":\"Av. Siempre Viva\"," +         
           "\"numero\":2012" +         
       "}," +         
       "\"soltero\":false," +         
       "\"nombreHijos\":[\"Marco\",\"Polo\",\"Lolita\"]," +         
       "\"cantHijos\":3," +         
       "\"fechaNacimiento\":{" +         
           "\"date\":3," +         
           "\"day\":4," +         
           "\"hours\":0," +         
           "\"minutes\":0," +         
           "\"month\":5," +         
           "\"seconds\":0," +         
           "\"time\":391921200000," +         
           "\"timezoneOffset\":180," +         
           "\"year\":82" +         
       "}" +
   "}";      

   JSONObject jsonPersona = JSONObject.fromObject(jsonStringPersona);
   String nombre = jsonPersona.getString("nombre");
   String apellido = jsonPersona.getString("apellido");
   JSONObject jsonDireccion = jsonPersona.getJSONObject("direccion");
   String calle = jsonDireccion.getString("calle");
   Integer numero = jsonDireccion.getInt("numero");
   JSONArray jsonArray = jsonPersona.getJSONArray("nombreHijos");
   String hijo1 = jsonArray.getString(0);
   String hijo2 = jsonArray.getString(1);
   String hijo3 = jsonArray.getString(2);

   System.out.println(nombre + " " + apellido);
   System.out.println("Vive en: " + calle + " " + numero);
   System.out.println("Sus hijos se llaman: " + hijo1 + ", " + hijo2 + " y " + hijo3);

Recordemos que un JSONObject implementa la interfaz java.util.Map, por lo que al levantar el string JSON en un objeto JSONObject ya tenemos un Mapa con el que podemos manipular los datos.

Si quisiéramos volcar el JSONObject en el Java Bean Persona podríamos hacer:

Persona persona = (Persona) JSONObject.toBean(jsonPersona, Persona.class);

Si miramos lo que tiene persona, vemos que la deserealización se ha realizado con éxito:

System.out.println(ReflectionToStringBuilder.toString(persona));

Otra funcionalidad muy interesante de JSON-lib es que permite pasar de JSON a XML y de XML a JSON. Por ejemplo, si quisiéramos serializar el jsonPersona a XML, tendríamos que hacer:

XMLSerializer xmlSerializer = new XMLSerializer();
String xml = xmlSerializer.write(jsonPersona);
System.out.println(xml);

Para pasar de XML a JSON es un poco más complicado (tampoco tanto). A quien le interese explorar esta funcionalidad, la documentación de la biblioteca nos recomienda este tutorial.

Cabe aclarar que para que funcione el XMLSerializer en tiempo de ejecución se necesita una dependencia no mencionada en la documentación y no incluida en el pom.xml de JSON-lib:

<dependency>
    <groupId>xom</groupId>
    <artifactId>xom</artifactId>
    <version>1.1</version>
</dependency>

JSON-RPC

JSON-RPC es un protocolo de llamadas a procedimientos remotos similar a XML-RPC, pero más liviano. Como dice la especificación, fue diseñado para ser simple. Se trata de un protocolo para un mecanismo típico de RPC en donde hay un cliente y un servidor que establecen una conexión. El cliente invoca métodos remotos publicados por el servidor enviando un request con el nombre del método y sus parámetros. El servidor contesta con un response que contiene los datos de respuesta. Tanto los request como los response son paquetes HTTP cuyo recurso (información transmitida) son objetos JSON.

El objeto request contiene tres propiedades:

method: un String que contiene el nombre del método a invocar
params: una Lista de Objetos para pasar como argumento del método
id: un identificador que se usa para matchear el request con el response

El objeto response contiene tres propiedades:

result: el Objeto resultado que retorna la invocación del método (debe ser nulo si hubo un error en la invocación)
error: un Objeto error que será nulo si no hubo error en la invocación del método
id: el mismo identificador del request

Las notificaciones son peticiones especiales que no reciben una respuesta. El objeto de notificación tiene las mismas dos primeras propiedades que un objeto request (method y params) y la propiedad id debe ser nula.

Un ejemplo de request podría ser:

{ "method" : "echo", "params" : ["Hello JSON-RPC"], "id" : 1 }

Lo que equivaldría a la invocación remota:

service.echo("Hello JSON-RPC")

Un ejemplo de response sin error para esta invocación podría ser:

{ "result" : "Hello JSON-RPC", "error" : null, "id" : 1 }

Un response con error:

{ "error" : { "message" : "Se ha producido un error de comunicación.", "code" : 15}, "id" : 1 }

jabsorb (Java to JavaScript Object Request Broker)

jabsorb es un framework Ajax/Web 2.0 simple y liviano. Permite realizar llamadas a métodos de objetos Java alojados en un servidor de aplicaciones web desde código JavaScript de forma transparente, como si el código de los objetos residiera en el browser cliente. Encapsula por completo la serialización y deserealización de los objetos y usa como protocolo de transporte el recién mencionado JSON-RPC.

Lamentablemente parece que la gente que desarrolla este broker nunca subió una distribución al repositorio público de Maven. De todas formas, yo lo he encontrado para bajar en un repositorio de Apache exclusivo del proyecto Apache Tuscany. Esto sirve para "zafar", pero bajo ningún punto de vista es una solución buena, porque dependemos de que la gente de Apache Tuscany mantenga este servidor y de que si aparece una nueva versión la actualicen. Por otra parte, no veo a la gente de jabsorb con intención de subir la biblioteca a un repositorio de Maven en un futuro cercano, considerando que esto está reportado como bug de prioridad media y continúa abierto desde el 16 de enero de 2008 (Ver Bug #40). Así que, para los que usamos Maven, tenemos que conformarnos con descargar la dependencia de algún repositorio de un proyecto público que encontremos o bajar el jar desde la página de jabsorb, a la antigua, y subirlo a un repositorio local que tengamos en nuestra empresa o usarlo directamente del repositorio local de nuestra máquina.

Si quieren descargar la dependencia desde el repositorio del proyecto Apache Tuscany, pueden agregar el servidor en el settings.xml de Maven:

<repository>
    <id>tuscany.apache.org</id>
    <name>Apache Tuscany</name>
    <url>http://svn.apache.org/repos/asf/tuscany/maven</url>
    <layout>default</layout>
</repository>

Y luego agregar la siguiente dependencia en pom.xml del proyecto:

<dependency>
    <groupId>org.jabsorb</groupId>
    <artifactId>jabsorb</artifactId>
    <version>1.3.1</version>
</dependency>

Veamos un ejemplo de uso muy sencillo, así entendemos la potencia de este mecanismo de RPC.

Dado que nuestro objetivo es comunicar código JavaScript que corre del lado del cliente con código Java que corre del lado del servidor, para probar jabsorb tendremos que armar una aplicación web. Si desean crear un proyecto de aplicación web para Eclipse y Tomcat usando un arquetipo de Maven2 y no saben cómo, pueden consultar los post HelloServlet Web Application con Maven2 y Eclipse y Plugin de Maven2 para Sysdeo de este mismo blog.

La biblioteca expone sólo dos componentes: JSONRPCBridge y JSONRPCServlet. Para registrar el JSONRPCServlet, quien maneja las peticiones HTTP, tendremos que agregar el mapeo en el web.xml de la aplicación:

<servlet>
    <servlet-name>JSONRPCServlet</servlet-name>
    <servlet-class>org.jabsorb.JSONRPCServlet</servlet-class>
    <init-param>
        <param-name>gzip_threshold</param-name>
        <param-value>200</param-value>
    </init-param>
</servlet>
<servlet-mapping> 
    <servlet-name>JSONRPCServlet</servlet-name>
    <url-pattern>/JSON-RPC</url-pattern>
</servlet-mapping>

El JSONRPCBridge mantiene las referencias a los objetos exportados, los objetos a los que se le pueden ejecutar invocaciones remotas. Tiene como responsabilidad decodificar las llamadas a los métodos, localizar el objeto y realizar la ejecución. Para que una única instancia de JSONRPCBridge esté disponible durante la conexión entre el cliente y el servidor, debemos crearla y guardarla en la sesión del servidor.

Por ejemplo, si estamos usando JSP para escribir los servlets podemos hacer:

<jsp:useBean id="JSONRPCBridge" scope="session" class="org.jabsorb.JSONRPCBridge" />

Luego, creamos una clase Java bien simple con el código que queremos ejecutar desde JavaScript. Por ejemplo:

package com.blogspot.tecnologiasjava.jarsorb.pruebas;

public class Hello {
   public String sayHello(String who) {
       return "hello " + who;
   }
}

Luego tendremos que registrar una instancia de la clase Hello en el bridge:

<% JSONRPCBridge.registerObject("hello", hello); %>

Listo. De esta forma tan simple hemos publicado todos los métodos públicos de la clase Hello para que puedan ser ejecutados de forma remota desde un navegador.

Veamos ahora el código JavaScript necesario para el lado del cliente:

var jsonrpc;

function onLoad() {
   jsonrpc = new JSONRpcClient("/JSON-RPC");
}

function clickHello() {
   var whoNode = document.getElementById("who");
   var result = jsonrpc.hello.sayHello(whoNode.value);
   alert("The server replied: " + result);
}

Veamos el jsp hello.jsp completo:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">

<jsp:useBean id="JSONRPCBridge" scope="session"
   class="org.jabsorb.JSONRPCBridge"/>

<jsp:useBean id="hello" scope="session"
   class="com.blogspot.tecnologiasjava.jarbsorb.pruebas.Hello"/>

<%JSONRPCBridge.registerObject("hello", hello);%>

<html>
   <head>
      <script type="text/javascript" src="jsonrpc.js"></script>
      <script type="text/javascript" src="hello.js"></script>
      <title>jabsorb Hello</title>
   </head>

   <body bgcolor="#ffffff" onLoad="onLoad()">
      <h2>jabsorb Hello</h2>
      <p>The jabsorb <em>Hello World</em> application.</p>
      <p>        
      <strong>Who:</strong>
       <input type="text" id="who" size="30" value="Adrian"/>&nbsp;        
       <input type="button" value="Say Hello" onclick="clickHello()"/>
      </p>
   </body>
</html>

Si queremos ejecutar este ejemplo, debemos bajarnos el ZIP de la página de descarga de jabsorb. Este ejemplo de Hello viene dentro. Pero no sólo por eso es importante bajarlo, además necesitamos el cliente JSON-RPC de jabsorb escrito en JavaScript, el archivo jsonrpc.js, que podemos copiar de la carpeta webapps/jsonrpc directo a la carpeta webapp de nuestro proyecto.

Con los archivos hello.js, hello.jsp y jsonrpc.js en nuestra carpeta webapp y la clase Hello.java en el paquete com.blogspot.tecnologiasjava.jarbsorb.pruebas, estamos listos para levantar el Tomcat (o el servidor de aplicaciones web que tengamos) y, si todo salió bien, cuando hagamos click en el botón de Say Hello del formulario de prueba de http://localhost:8080/jabsorb_pruebas/hello.jsp, el alert nos saludará con el texto The server replied: hello Adrian, o el nombre que hayamos escrito en el input text.

La línea más importante para analizar en el código es ésta:

var result = jsonrpc.hello.sayHello(whoNode.value);

Aquí es donde toda la magia de jabsorb y JSON-RPC muestra su esplendor. Una línea de código JavaScript que ejecuta un método de una clase Java ubicada en el servidor. Los paquetes JSON-RPC van por debajo, son invisibles para el programador.

Si nos ponemos a pensar un poco, este mecanismo de RPC transparente que proporciona jabsorb tiene bastantes similitudes con los mecanismos de RPC que proveen otros frameworks bastante más pesados, como por ejemplo EJB3. Claro que EJB3 es una plataforma y provee muchas más funcionalidades que obviamente JSON-RPC no provee, ni intenta proveer, pero lo asombroso es que, con tan poco y con tanta simpleza, las funcionalidades provistas por jabsorb y otras tecnologías livianas basadas en JSON resultan muy poderosas.

Referencias

JSF 1.2: Los Values de los InputText Number y Boolean que Deberían ser Null

2009-11-09T05:15:00.000-08:00

Cuando uno define un input-text en JSF (que no es requerido) para un valor que debería ser un Number (Integer, Double, etc) o un Boolean, y al correrlo el usuario lo deja vacío, podemos ver, con desagrado, que el valor de esa variable se ha convertido en cero o false, respectivamente. En la mayoría de los casos, este comportamiento no es el deseado cuando estamos trabajando con objetos y no con primitivas. Queremos que el valor permanezca en null y no que se le asigne un valor incorrecto.

Aunque cueste creerlo, éste no es realmente un bug de JavaServer Faces directamente, sino del servidor de aplicaciones que se esté usando. A partir de la versión 1.2, JSF utilizará la implementación del ELParser provista por el servidor web para evaluar las expresiones JSF. Por lo tanto, dependiendo del servidor que estén usando puede que nunca se hayan topado con este bug (de hecho el bug es totalmente dependiente de la plataforma en la que se esté corriendo). Este problema es muy común en los Apache Tomcat de la versión 6.0.16 para arriba. (Yo uso la 6.0.20 y me pasa.)

Para solucionarlo, no se rompan la cabeza destrozando el código, agregando converters horribles que sólo lo van a hacer sentir peores programadores a ustedes, o lo que sea. Si usan Tomcat, basta con agregar este argumento a la Java Virtual Machine (JVM) cuando vayan a ejecutar el startup:

-Dorg.apache.el.parser.COERCE_TO_ZERO=false

(No sé a quién se le pudo ocurrir que por defecto fuera true.)

Si están levantando el Tomcat desde una consola de Linux, deben agregarle el argumento a la variable JAVA_OPTS en el catalina.sh de la carpeta lib. Por ejemplo, yo tengo:

if [ -z "$LOGGING_MANAGER" ]; then
    JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Dorg.apache.el.parser.COERCE_TO_ZERO=false"
else
    JAVA_OPTS="$JAVA_OPTS $LOGGING_MANAGER"
fi

Si usan Windows deberán hacer lo mismo con la variable de entorno JAVA_OPTS, pero en el catalina.bat.

IMPORTANTE: Si levantan el Tomcat desde el Eclipse (usando el plugin Sysdeo) tienen que agregarlo como JVM Parameter. Para eso van a Window --> Preferences --> Tomcat --> JVM Settings --> Append to JVM Parameters y escriben -Dorg.apache.el.parser.COERCE_TO_ZERO=false como indiqué más arriba.

¡Ya está! Si todo salió bien, la próxima vez que levanten el Tomcat y corran la aplicación, los values de los input-text no agregarán más ceros en los Numbers, ni false en los Booleans.

------------------------------------------
http://forums.sun.com/thread.jspa?threadID=5359447
https://jsp-spec-public.dev.java.net/issues/show_bug.cgi?id=183

Construir una aplicación Web (JSF, RichFaces y Facelets) con Maven

2009-08-09T12:12:00.000-07:00

En este post nos proponemos construir una aplicacion web JSF utilizando el arquetipo maven-archetype-jsfwebapp disponible para Maven. En el sitio oficial de RichFaces existe un tutorial para utilizar este arquetipo. Nuestra contribución es realizar algunas modificaciones a la aplicacion resultante para integrar Facelets.

Versiones Utilizadas
Maven2
Eclipse Ganymede

Que es un arquetipo? Un arquetipo es la plantilla que se utilizara para crear la estructura y archivos base necesarios para obtener un proyecto funcional. En este caso una aplicacion jsf.

Paso 1) Agregar repositorios al archivo settings.xml de Maven
Agregamos al archivo DIRECTORIO_INSTALACION_MAVEN/conf/settings.xml el siguiente profile que contiene los repositorios de RichFaces.


   
<profile>
    <id>jsf-app-profile</id>
    <repositories>
        <repository>
            <releases>
                <enabled>true</enabled>
            </releases>
            <snapshots>
                <enabled>true</enabled>
                <updatePolicy>always</updatePolicy>
            </snapshots>
            <id>snapshots.jboss.org</id>
            <name>Snapshot Jboss Repository for Maven</name>
            <url>http://snapshots.jboss.org/maven2/</url>
            <layout>default</layout>
        </repository>
        <repository>
            <releases>
                <enabled>true</enabled>
            </releases>
            <snapshots>
                <enabled>true</enabled>
                <updatePolicy>always</updatePolicy>
            </snapshots>
            <id>repository.jboss.com</id>
            <name>Jboss Repository for Maven</name>
            <url>http://repository.jboss.com/maven2/</url>
            <layout>default</layout>
        </repository>
    </repositories>
</profile>

Paso 2) Agregar el perfil a los perfiles activos
Para que el perfil que agregamos sea visible para Maven, el tag activeProfiles del settings.xml debe quedar asi:


    
<activeProfiles>
  <activeProfile>jsf-app-profile</activeProfile>
</activeProfiles>

Paso 3) Crear el Proyecto

En una consola tipeamos:


mvn archetype:generate -DarchetypeGroupId=org.richfaces.cdk -DarchetypeArtifactId=maven-archetype-jsfwebapp -DarchetypeVersion=3.3.1-SNAPSHOT -DgroupId=com.blogspot.tecnologiasjava.controller -DartifactId=AppWeb

Donde DgroupId es el package de los Managed Beans y DartifactId el nombre del proyecto.

Paso 4) Agregar Dependencias

Con el comando anterior se creo una carpeta llamada AppWeb que contiene la estructura del proyecto. Ahora debemos agregar unas dependencias al pom.xml del proyecto para que compile.
Dentro del pom.xml buscamos el tag dependencies, este deberia quedar como:



  <dependencies>
      <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>3.8.1</version>
    <scope>test</scope>
      </dependency>
      <dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>servlet-api</artifactId>
    <version>2.4</version>
    <scope>provided</scope>
      </dependency>
      <dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>jsp-api</artifactId>
    <version>2.0</version>
    <scope>provided</scope>
      </dependency>
      <dependency>
    <groupId>jstl</groupId>
    <artifactId>jstl</artifactId>
    <version>1.1.2</version>
      </dependency>
      <dependency>
    <groupId>javax.servlet.jsp</groupId>
    <artifactId>jsp-api</artifactId>
    <version>2.1</version>
    <scope>provided</scope>
      </dependency>
      <dependency>
    <groupId>javax.faces</groupId>
    <artifactId>jsf-api</artifactId>
    <version>1.2_12</version>
      </dependency>
      <dependency>
    <groupId>javax.faces</groupId>
    <artifactId>jsf-impl</artifactId>
    <version>1.2_12</version>
      </dependency>
      <dependency>
    <groupId>javax.el</groupId>
    <artifactId>el-api</artifactId>
    <version>1.0</version>
    <scope>provided</scope>
      </dependency>
      <dependency>
    <groupId>el-impl</groupId>
    <artifactId>el-impl</artifactId>
    <version>1.0</version>
    <scope>provided</scope>
      </dependency>
      <dependency>
    <groupId>javax.annotation</groupId>
    <artifactId>jsr250-api</artifactId>
    <version>1.0</version>
      </dependency>
      <!-- RichFaces libraries -->
      <dependency>
    <groupId>org.richfaces.framework</groupId>
    <artifactId>richfaces-api</artifactId>
    <version>3.3.1-SNAPSHOT</version>
      </dependency>
      <dependency>
    <groupId>org.richfaces.framework</groupId>
    <artifactId>richfaces-impl</artifactId>
    <version>3.3.1-SNAPSHOT</version>
      </dependency>
      <dependency>
    <groupId>org.richfaces.ui</groupId>
    <artifactId>richfaces-ui</artifactId>
    <version>3.3.1-SNAPSHOT</version>
      </dependency>
      <!-- Facelets -->
      <dependency>  
       <groupId>com.sun.facelets</groupId>  
       <artifactId>jsf-facelets</artifactId>  
       <version>1.1.14</version>  
     </dependency>  
  </dependencies>

Paso 5) Compilar, empaquetar e instalar

Dentro de la carpeta del proyecto ejecutamos el comando mvn install para que el proyecto compile, se empaquete y sea instalado en el repositorio local.

Paso 6) Convertir el proyecto en un proyecto eclipse

Ejecutamos el comando mvn eclipse:eclipse

Paso 7) Convertir el proyecto en un proyecto tomcat

Ejecutamos el comando mvn sysdeo-tomcat:generate

Paso 8) Incluyendo los jars

Ejecutamos el comando mvn war:inplace

Para desplegar la aplicación vamos a utilizar el pluging de Sysdeo Eclipse Tomcat . Lo podes descargar desde http://www.eclipsetotale.com/tomcatPlugin.html#A3. Se descomprime el zip y se copia la carpeta com.sysdeo.eclipse.tomcat_3.2.1 a la carpeta plugins del Eclipse. Reiniciamos el IDE para que tome los cambios. Ultimo Paso, configurar el tomcat que vamos a utilizar. En el menu Windows/Preferences/Tomcat configuramos el path y la versión de Tomcat

Paso 8) Importar el proyecto en eclipse
Importamos el proyecto haciendo click en la opción Import... del menú File.

Hacemos click en Existing Projects into Workspace y seleccionamos la carpeta del proyecto.

Importante: Si te falta la variable M2_REPO el proyecto no va a compilar. Para definirla hace click sobre el menu Windows/Preferences/Java/Build Path/Classpath Variables.

Paso 9) Modificar el web.xml
Reemplazamos el contenido del web.xml por el siguiente que tiene configurado RichFaces y Facelets


    
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
 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/web-app_2_4.xsd">
 <display-name>Greeter</display-name>
 <!-- AJAX View handlers -->
  <context-param>
    <param-name>org.ajax4jsf.VIEW_HANDLERS</param-name>
    <param-value>com.sun.facelets.FaceletViewHandler</param-value>
  </context-param>

  <!-- Rich Faces -->
    <context-param>
        <param-name>org.richfaces.SKIN</param-name>
        <param-value>blueSky</param-value>
    </context-param>
    
    
  <!-- Making the RichFaces skin spread to standard HTML controls -->
  <context-param>
      <param-name>org.richfaces.CONTROL_SKINNING</param-name>
      <param-value>enable</param-value>
  </context-param>
    
    <context-param>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>server</param-value>
    </context-param>
    
      <!-- Faces Servlet -->
    <context-param>
        <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
        <param-value>.xhtml</param-value>
    </context-param>
    
    <filter> 
        <display-name>RichFaces Filter</display-name> 
        <filter-name>richfaces</filter-name> 
        <filter-class>org.ajax4jsf.Filter</filter-class> 
         <init-param>
            <param-name>createTempFiles</param-name>
            <param-value>false</param-value>
        </init-param>
        <init-param>
            <param-name>maxRequestSize</param-name>
            <param-value>1000000</param-value>
        </init-param>
    </filter> 
    <filter-mapping> 
        <filter-name>richfaces</filter-name> 
        <servlet-name>Faces Servlet</servlet-name>
        <dispatcher>REQUEST</dispatcher>
        <dispatcher>FORWARD</dispatcher>
        <dispatcher>INCLUDE</dispatcher>
    </filter-mapping>
    <listener>
        <listener-class>com.sun.faces.config.ConfigureListener</listener-class>
    </listener>
    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <!-- Faces Servlet Mapping -->
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.xhtml</url-pattern>
    </servlet-mapping>
        
  <welcome-file-list>
    <welcome-file>index.xhtml</welcome-file>
  </welcome-file-list>

 </web-app>

Paso 10) Crear template.xhtml

Este archivo sera la base para todas las páginas de la aplicación web. Incluimos un peque;o menu y definimos el tag ui:include que nos permitira incluir dentro de esta plantilla lo que definamos dentro del campo ui:define name="body" de los otros archivos.



<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
  xmlns:ui="http://java.sun.com/jsf/facelets"
  xmlns:h="http://java.sun.com/jsf/html"
  xmlns:f="http://java.sun.com/jsf/core"
  xmlns:a4j="http://richfaces.org/a4j"
  xmlns:rich="http://richfaces.org/rich">
<head>
<title><h:outputText value="aplicacion JSF" /></title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<f:view>
  <a4j:form>
    <rich:toolBar>
      <rich:dropDownMenu value="Productos">
        <rich:menuItem submitMode="none">
          <h:outputLink value="listar-productos.xhtml">
            <h:outputText value="Listar Productos" />
          </h:outputLink>
        </rich:menuItem>
      </rich:dropDownMenu>
    </rich:toolBar>
  </a4j:form>
  <rich:spacer height="20" />
</f:view>
<p>
  <ui:insert name="body" />
</p>
</body>
</html>

Paso 11) Reescribimos el index.xhtml

  
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
  xmlns:ui="http://java.sun.com/jsf/facelets"
  xmlns:h="http://java.sun.com/jsf/html"
  xmlns:f="http://java.sun.com/jsf/core"
  xmlns:s="http://jboss.com/products/seam/taglib"
  xmlns:rich="http://richfaces.org/rich">
<body>
<ui:composition template="/template.xhtml">
  <ui:define name="body">
  </ui:define>
</ui:composition>
</body>
</html>

Paso 12) Más Páginas

Agregamos otra página que es utilizada por el menú definido en el template.xhtml llamada listar-productos.xhmtl


  
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
  xmlns:ui="http://java.sun.com/jsf/facelets"
  xmlns:h="http://java.sun.com/jsf/html"
  xmlns:f="http://java.sun.com/jsf/core"
  xmlns:s="http://jboss.com/products/seam/taglib"
  xmlns:rich="http://richfaces.org/rich">
<body>
<ui:composition template="/template.xhtml">
  <ui:define name="body">
    <h:outputText value="Productos" />
  </ui:define>
</ui:composition>
</body>
</html>

Paso 13) Actualizar el contexto del tomcat

Para que el tomcat despliegue la aplicación, debemos actualizar el contexto del mismo. Abrimos el menú contextual del proyecto y hacemos click sobre la opción Tomcat Project/Update context definition

Importante: Para no tener problemas de librerías tenemos que deshabilitar el DevLoader, en otro post hablaremos de esta funcionalidad. En el menú contextual del proyecto buscamos la opción Properties. Dentro de la ventana Properties hacemos click en Tomcat.
Una de las tres pestañas se llama DevLoader Classpath. En esta pestaña desactivar el checkbox.

Paso 14) Desplegar la aplicación
Hacemos click sobre el icono del tomcat para levantarlo.

Abrimos un navegador y tipeamos http:localhost:8008/AppWeb, si todo salio bien deberíamos ver nuesta aplicación, ahora un poco vacia.

Eclipse Galileo

2009-06-24T10:58:00.000-07:00

Ha salido una nueva versión del IDE más popular del mundo: Eclipse 3.5. La noticia fue anunciada hoy mismo por la Eclipse Foundation y nosotros nos hemos enterado por esta nota en InfoQ:

"The Eclipse Foundation today announced the release of Eclipse Galileo, the simultaneous release of 33 projects, including the venerable Eclipse JDT. As well as the new features covered by InfoQ already, the Galileo release includes the PHP Development Tools Project, as well as stalwarts like modelling packages and the persistence layer EclipseLink (formerly known as Oracle's TopLink).

For component developers, the Galileo release also adds the latest OSGi Declarative Services to the standard Equinox runtime, which is included in the RCP client. The Mac OS X runtime is also given a boost, as the new Eclipse is based on Cocoa (rather than the older Carbon based APIs) which give new features such as dialog sheets as well as a 64-bit version capable of running on the latest Intel 64-bit Java 6.

Despite originally been known by its namesake Java IDE, the Eclipse platform has grown far beyond its humble beginnings and provides the basis of many languages (C, PHP, HTML, JavaScript, and other Dynamic languages, not to mention other IDEs developed outside of the Eclipse Foundation like Scala and Python). The Eclipse Runtime project provides not only the base Equinox OSGi runtime, but also generic communication framework ECF, which is used by the update mechanism P2 to download bundles from HTTP (or other services like Bitorrent or in future communicate with services like Google Wave).

Ian Bull of EclipseSource has been publishing a top ten feature list:

P2 provisioning which provides for a more efficient update process for Eclipse
OSGi Declarative Services, which allow OSGi services to be configured and installed based on XML prior to the start of the bundle's service
Improved target platform management, which allows the runtime platform to be configured easier
Mylyn WikiText, which can be used to edit bugs via Mylyn or transform into other documentation formats like DocBook
The addition of the Eclipse Memory Analyser, which can analyse the JVM's heap usage
Install into Self, which allows plugins to be developed and installed into the currently running Eclipse platform
Eclipse Modeling Project refinements, which reduces the size of the EMF runtime requirements
Improved RAP styles to allow your RAP based application to be customised
Enhanced JAvaScript bridge, which allows embedding of widgets like Google Maps into an SWT browser
Java compare editor enhancements which allow JavaDoc hovers, hyperlinking and other goodness from the compare page

A number of presentations on Galileo in action are being organised for June 26, as well as a number of DemoCamps across the globe, demonstrating new features."

Fuente: http://www.infoq.com/news/2009/06/eclipse-galileo-released

El Futuro de Java EE: EJB 3.1

2009-04-23T13:40:00.000-07:00

La especificación Java EE 6 está por quedar terminada, y la mayoría de las tecnologías que abarca están llegando a su versión final, todo con altas expectativas. Definitivamente 2009 va a ser un año importante para Java EE.

Muchas características y nuevas oportunidades surgen con EJB 3.1. EJB 3.1 le permite a los arquitectos y a los desarrolladores contar con un conjunto rico de nuevas funcionalidades, permitiendo extender la cantidad de desafíos que puede cubrir esta tecnología. Esta nueva versión demuestra mucha madurez, y hará que Java tenga una posición más sólida que nunca en el lado del servidor.

Algunas de las mejoras y nuevos features que EJB 3.1 especifica son:

Vistas sin interfaz: SessionBeans sin necesidad de escribir interfaz. Una Vista expone todos los métodos públicos de un bean de la misma forma que en EJB 3.0 lo hacía una interfaz Local o Remota.
Singleton Session Beans: Ahora hay tres tipos de Session Beans: stateless, stateful y singleton. Los nuevos SessionBeans son Singletons que se instancian una única vez por aplicación y se comparten entre todos los clientes, permitiendo que el contenedor maneje su ciclo de vida y los accesos concurrentes.
Invocaciones asincrónicas: Usando @Asynchronous y la interfaz Future de Java5, puede utilizarse en todos los tipos de beans, en todas las vistas. Puede aplicarse a un método o a una clase.
Nombres JNDI globales: La especificación ahora define nombres JNDI globales para registrar a los EJB. ¡Ahora tenemos nombres JNDI portables! En EJB 3.0 los nombres JNDI son específicos de cada contenedor.
Timer-Service: Posibilidad de agregar Timers declarativos, con anotaciones o descriptores (hasta ahora la interfaz TimerService sólo era programática).
EJB Lite: Sub-conjunto estándar de EJB para aplicaciones que no necesitan del conjunto completo del API.
Empaquetado de EJB simplificado: EJB 3.1 permite empaquetar EJBs dentro de un archivo war.
Contenedores EJB embebibles: Un cliente Java SE ahora puede instanciar un contenedor EJB (clase EJBContainer) que se ejecuta dentro de su propia JVM y classloader. Este contenedor embebible provee un conjunto básico de servicios (EJB Lite) que le permiten al cliente beneficiarse del uso de EJBs sin necesitar de un contenedor Java EE.

Todo esto lo saqué de este excelente artículo publicado hoy mismo por Leonardo De Seta en DosIdeas y en español:
http://www.dosideas.com/java/528-ejb-31-un-paso-importante-hacia-la-madurez.html

En el artículo se explica cada uno de los features con detalle y se muestran varios ejemplos. Es altamente recomendable.

El artículo está basado en el artículo:
http://www.theserverside.com/tt/articles/article.tss?l=EJB3-1Maturity

Me enteré de este post, a través de javaHispano:
http://www.javahispano.org/contenidos/es/lo_nuevo_en_ejb_3_1/?utm_source=feed&utm_medium=feed&utm_campaign=feed

Apache Commons. Api BeanUtils

2009-03-08T09:18:00.000-07:00

Links
http://commons.apache.org/
http://commons.apache.org/beanutils/
http://oreilly.com/catalog/9780596007065/
http://commons.apache.org/beanutils/v1.8.0/apidocs/index.html

Que harían si tuvieran que copiar las propiedades de un objeto a otro? Opción 1: Ejecutar getters y setters para cada propiedad del objeto. Opción 2: Utilizar reflection para crear un método genérico que sirva para copiar objetos de cualquier clase.

La segunda opción resulta mas apropiada, ya que podríamos encapsularlo en una clase Util para utilizarlo en nuestros proyectos. Sin embargo.. esta api existe, y es BeanUtils.

Que condiciones deben cumplir los objetos que serán "procesados" utilizando con esta api? Los mismos que un JavaBean, deben tener un constructor sin argumentos y sus propiedades deben ser accesibles mediante métodos get y set que siguen una convención de nomenclatura estándar.

Claramente BeanUtils ofrece mayores utilidades que la de copiar un bean, también permite clonarlos, invocar métodos de forma dinámica, crear beans dinámicos en runtime, etc... para implementar todas utilidades, BeanUtils hace uso de la api reflections.

Una aclaración importante de las utilidades copiar y clonar, es que si el objeto a copiar/clonar referencia a otro objeto, entonces cuando se quiera copiar esta propiedad, solo se creara una referencia al mismo objeto.

Copiar las propiedades de un bean a otro bean de la misma clase.

Por ejemplo si tenemos la clase Person


package com.blogspot.tecnologiasjava;
import org.apache.commons.lang.builder.ReflectionToStringBuilder;

public class Person {
  
  private String name;
  private int age;
  private Date birthDay;

  /** Omito los getter/setters para mayor legibilidad */

  @Override
  public String toString() {
    return ReflectionToStringBuilder.toString(this);
  }
}

Y el siguiente test

public class Test {

   public static void main(String[] args) throws IllegalAccessException, InvocationTargetException {
     
       Person personOne = new Person();
       Person personTwo = new Person();
     
       personOne.setName("Adrian");
       personOne.setAge(26);
       personOne.setBirthDay(new Date());
       BeanUtils.copyProperties(personTwo, personOne);
       System.out.println("PersonOne: "+personOne);
       System.out.println("PersonTwo: "+personTwo);
   }
}

Lo que obtenemos como resultado, es que las propiedades de PersonOne se copiaron en PersonTwo, por eso tenemos la siguiente salida.

PersonOne: com.blogspot.tecnologiasjava.model.Person@16897b2[name=Adrian,age=26,birthDay=Sun Mar 08 13:22:03 ARST 2009]
PersonTwo: com.blogspot.tecnologiasjava.model.Person@a401c2[name=Adrian,age=26,birthDay=Sun Mar 08 13:22:03 ARST 2009]

Copiar las propiedades de un bean a otro bean de otra clase.

En este caso cabe aclarar que solo se copian las propiedades que tengan en común los dos objetos, aca no estoy hablando de herencia, solo digo que si una clase X y otra clase Y tienen color como atributo en comun, entonces ese es el atributo que se copiara.

Por ejemplo, sumamos a nuestro modelo la clase Alien

public class Alien{

   private String name;
   private int age;
   public String color;

  /** Omito los getter/setters para mayor legibilidad */
 
   @Override
   public String toString() {
       return ReflectionToStringBuilder.toString(this);
   }
}

Como podemos ver, la clase Alien tiene en común con la clase Person los atributos name y age. Entonces, si ejecutamos el siguiente test.


public class Test {

  public static void main(String[] args) throws IllegalAccessException, InvocationTargetException {
   
      Person person = new Person();
      Alien alien = new Alien();
   
      person.setName("Adrian");
      person.setAge(26);
      person.setBirthDay(new Date());
      BeanUtils.copyProperties(alien, person);
      System.out.println("person: "+person);
      System.out.println("alien: "+alien);
  }
}

Obtenemos como resultado

person: com.blogspot.tecnologiasjava.model.Person@16f8cd0[name=Adrian,age=26,birthDay=Sun Mar 08 13:30:28 ARST 2009]
alien: com.blogspot.tecnologiasjava.model.Alien@15fea60[name=Adrian,age=26,color=]

Aca podemos ver que los atributos en común fueron copiados del objeto origen al objeto destino, mientras que color que era propio de la clase Alien quedo en null.

Clonar beans

En este caso tenemos la restricción que el objeto clonado va a ser un objeto de la misma clase que el objeto que se desea clonar.

Por ejemplo, si ejecutamos el siguiente test


public class Test {

  public static void main(String[] args) throws IllegalAccessException, InstantiationException, InvocationTargetException, NoSuchMethodException {
   
      Person person = new Person();
      person.setName("Adrian");
      person.setAge(26);
      person.setBirthDay(new Date());
   
      Person clone = (Person)BeanUtils.cloneBean(person);
      System.out.println("person: "+person);
      System.out.println("clone: "+clone);
  }
}

Obtenemos en consola:

person: com.blogspot.tecnologiasjava.model.Person@55571e[name=Adrian,age=26,birthDay=Sun Mar 08 13:36:10 ARST 2009]
clone: com.blogspot.tecnologiasjava.model.Person@1201a25[name=Adrian,age=26,birthDay=Sun Mar 08 13:36:10 ARST 2009]

Como pueden ver, la dirección de memoria del objeto clonado es distinta a la del objeto original.

Crear un bean dinámico en Runtime.

En ocasiones quizá no queramos llenar nuestro código con clases que solo serán utilizadas una vez, y a la cual no le vemos cabida en nuestro modelo de datos. En estos casos y seguramente en muchos mas, tendrán la necesidad de crear una clase dinámicamente. Por ejemplo, crearemos un dinamic bean similar a nuestra clase Person.


public class Test {

  public static void main(String[] args) throws IllegalAccessException, InstantiationException {
   
      DynaProperty[] beanProperties = new DynaProperty[]{
              new DynaProperty("name", String.class),
              new DynaProperty("age", Integer.class),
              new DynaProperty("birthDay", Date.class)
      };
   
      BasicDynaClass personClass = new BasicDynaClass("Person", BasicDynaBean.class, beanProperties);
      DynaBean person = personClass.newInstance( );
   
      person.set( "name", "Adrian" );
      person.set( "age", 26 );
      person.set( "birthDay", new Date() );
      System.out.println(person.get("name"));
      System.out.println(person.get("age"));
   
  }
}

La clase BasicDynaClass es una clase básica, mirando la documentación de BeanUtils también encontraran la clase ResultSetDynaClass, que permite poder tratar los resultados de un select como si fueran javabeans.


Connection conn = ...;
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select account_id, name from customers");
Iterator rows = (new ResultSetDynaClass(rs)).iterator();
while (rows.hasNext()) {
  DynaBean row = (DynaBean) rows.next();
  System.out.println("Account number is " +row.get("account_id") +
      " and name is " + row.get("name"));
}
rs.close();
stmt.close()

y en caso que la conexión se haya cerrado, directamente pueden solicitar una lista de bean dinámicos que representen los resultados.

Connection conn = ...;  // Acquire connection from pool
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT ...");
RowSetDynaClass rsdc = new RowSetDynaClass(rs);
rs.close();
stmt.close();
...;                    // Return connection to pool
List rows = rsdc.getRows();
 ...;                   // Process the rows as desired

Apache Commons. Api Lang.

2009-02-18T11:40:00.000-08:00

Apache commons en un conjunto de apis diseñadas para simplificar nuestro código, y sobre todo para no reinventar la rueda. Por ejemplo cuando necesitamos convertir un xml a un objeto, no tenemos que lidiar con dom4j, porque ya existe Digester (el cual tratare en un post posterior). Esta api permite que muchas lineas de código se simplifiquen haciendo el código simple y legible.

A continuación, en este y los siguientes post,comentaré las funcionalidades que uso diariamente en mi trabajo y otras que me llamaron la atención cuando me puse a leer la documentación y el libro Jakarta Commons Cookbook, este último esta un poco desactualizado por lo cual quizá encuentren cosas que ahora pueden hacer nativamente con java.

Links
http://commons.apache.org/
http://commons.apache.org/lang/
http://oreilly.com/catalog/9780596007065/

LANG

Esta api extiende la funcionalidad de las clases incluidas en java.lang. Por ejemplo, tenemos un util para las clases String, Boolean, Integer, etc. También tenemos clases que nos ayudaran a trabajar con Fracciones por ejemplo.

Automatizar implementación de ToString

Definamos una clase Person



package com.blogspot.tecnologiasjava;

import org.apache.commons.lang.builder.ReflectionToStringBuilder;


public class Person {
  
  private String name;
  private int age;

  /** Omito los getter/setters para mayor legibilidad */

  @Override
  public String toString() {
    return ReflectionToStringBuilder.toString(this);
  }
}

Si ejecutamos un pequeño test



  public static void main(String[] args) {
    
    Person person = new Person();

    person.setName("Adrian");
    person.setAge(26);
    System.out.println(person);

  }

En consola tendremos

com.blogspot.tecnologiasjava.Person@addbf1[name=Adrian,age=26]

Obviamente a simple vista es una pavada, pero muy simple y rápido de implementar cuando estamos haciendo debugging.

Automatizar hashCode y equals

Bueno esto es muy interesante, cuando se implementa el método equals, tenemos que devolver true si un objeto es igual a otro y false en caso contrario. Pero que implica que un objeto sea igual a otro, no depende de su dirección de memoria sino de sus atributos. Supongamos que tenemos nuestra clase Person y suponemos que dos instancias de person son iguales si tienen el mismo nombre, entonces con esta api podríamos definir en la clase Person.



  @Override
  public boolean equals(Object obj) {
    if(obj==null || !Person.class.isAssignableFrom(obj.getClass())){

      return false;
    }
    Person p = (Person)obj;
    return (new EqualsBuilder().append(this.name, p.name)).isEquals();
  }

en caso que dos personas sean iguales si tienen el mismo nombre y la misma edad deberiamos agregar al metodo append del EqualsBuilder



  @Override
  public boolean equals(Object obj) {
    if(obj==null || !Person.class.isAssignableFrom(obj.getClass())){
      return false;
    }
    Person p = (Person)obj;
    return (new EqualsBuilder().append(this.name, p.name).append(this.age, p.age)).isEquals();
  }

Por último, si necesitamos sobrecargar el método hashCode podemos escribir los siguiente.



  @Override
  public int hashCode() {
    return new HashCodeBuilder(17,37).append(name).append(age).toHashCode();
  }

Utilidades para Arrays

ArrayUtils dispone de varios métodos para trabajar con arrays nativos, por ejemplo:

   
    int[] intArray = new int[]{1,2,3,4,5};
    /** Consulta si el array contiene el numero 5 */
    System.out.println(ArrayUtils.contains(intArray, 5));
    
    /** Crea un nuevo array con el 6 agregado*/
    int[] intArrayWithSix =ArrayUtils.add(intArray,6);
    
    /** Clona el array */
    int[] intArrayClone = ArrayUtils.clone(intArray);

De que nos ahorramos? y básicamente de escribir uno o varios for. Ya que están encapsulados en la api.

Trabajar con Fracciones

Disponemos de una clase Fraction que incluye las operaciones básicas. Interesante, aunque no le encontré una utilidad.



  Fraction fractionOne = Fraction.getFraction(5, 4);
  Fraction fractionTwo = Fraction.FOUR_FIFTHS;
    
  Fraction result =fractionOne.add(fractionTwo);
  System.out.println(result);

Crear un String random.

Tampoco se me ocurre una utilidad en este momento para esta clase. Básicamente crea un string random con la longitud indicada al método e incluye números y letras según nosotros decidamos.



    System.out.println(RandomStringUtils.random(23,true,true));

Resultado: kiqUv0dIYlWtrjQCmNrzlpj

En el próximo post comentare la api BeanUtils.

El Problema de las Dependencias Transitivas de Maven y Cómo Excluirlas

2009-02-15T06:18:00.000-08:00

Esta semana, un pequeño problemita con Maven y, particularmente, con la librería jabsorb, que provee una implementación del protocolo JSON-RPC, me ha traído uno de esos pequeños-grandes dolores de cabeza que todos los programadores bien conocemos.

Resulta que no encontré un repositorio de Maven que contenga la librería de jabsorb, así que tuve que subirla a mano a un repositorio local de mi empresa. Como el source de jabsorb provee un pom.xml, me confié en que todo estaba ok y subí el jar y el pom con el comando deploy:deploy-file. Se puede encontrar información aquí sobre este comando.

# mvn deploy:deploy-file -DgroupId=com.blogspot.tecnologiasjava.proyecto -DartifactId=Proyecto -Dversion=1.1.1-SNAPSHOT -Dpackaging= jar -Dfile=[Path del jabosorb.jar] -DpomFile=[Path del pom del jabsorb] -Durl=scpexe://maven2-repo -DrepositoryId=maven2-repo-local

Al armar mi pom.xml, ingenuamente incluí la dependencia del jabsorb de esta forma:


<dependency>
  <groupid>org.jabsorb</groupid>
  <artifactid>jabsorb</artifactid>
  <version>1.3</version>
</dependency>

Al armar el proyecto de Eclipse y compilar no hubo problemas. Yo uso el plugin de Eclipse para Tomcat, Sysdeo, y el plugin de Maven, sysdeo-tomcat, para generar un proyecto de Tomcat con Sysdeo, así que ningún problema.

Es más, la aplicación la corrí sin problemas desde mi navegador web y todo funcionó perfecto.

Cuando deployé el war de mi proyecto en un servidor JBoss compartido con otras aplicaciones, donde hay otros wars deployados, todo se vino abajo. El compilador Jasper que provee el JBoss Web para compilar JSP se hizo pedazos y todas las páginas JSP que albergaba el contenedor de aplicaciones escupían este error y no se podían mostrar:


java.lang.LinkageError: Class javax/el/ExpressionFactory violates loader constraints
  java.lang.ClassLoader.defineClass1(Native Method)
  java.lang.ClassLoader.defineClass(Unknown Source)
  java.security.SecureClassLoader.defineClass(Unknown Source)
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1817)
  org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:872)
  org.jboss.web.tomcat.service.WebAppClassLoader.findClass(WebAppClassLoader.java:139)
  org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1325)
  org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204)
  java.lang.ClassLoader.loadClassInternal(Unknown Source)
org.apache.jasper.runtime.JspApplicationContextImpl.getExpressionFactory(JspApplicationContextImpl.java:80)
  org.apache.jsp.WEB_002dINF.jsp.usuarios.loginHB_jsp._jspInit(loginHB_jsp.java:46)
  org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:52)
  org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:159)
  org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:323)
  org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
  org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
  javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
...

Como cualquier Error/Exception de este tipo, el stack seguía hasta el infinito.

Tardé un tiempo para darme cuenta de que el problema era que mi war estaba incluyendo las librerías de jsp-2.1-6.16.jar, jsp-api-2.1-6.16.jar y servlet-api-2.5.6.16.jar de vaya a saber qué implementación. Si prestamos atención al Error lanzado por el application container nos damos cuenta de que hay un problema de compatibilidad en la implementación de la clase javax.el.ExpressionFactory. Si hacemos una búsqueda en findJar vemos que, gualá, la clase está en el jar de jsp-api. Era obvio que mi war, al incluir el jsp-api-2.1-6.16.jar entre sus librerías, estaba reemplazando el jsp-api de Jasper que JBoss usa para compilar los archivos JSP. El ClassLoader de JBoss estaba cargando la clase ExpressionFactory de mi jar y no de su propia carpeta de librerías. Y lo peor era que la usaba para todas las aplicaciones deployadas en el servidor. Por alguna razón le daba prioridad a mi jsp-api, antes que a los demás que hubiere en su repositorio de librerías compartidas entre aplicaciones.

Pero quién estaba incluyendo esos jars. Era obvio que yo no. Sí estaba incluyendo servlet-api para poder compilar mi código, pero lo hacía utilizando el scope de provided, que para Maven significa: incluí el jar para que mi proyecto compile, pero al deployar, no lo incluyas entre las librerías requeridas, ya que el application server ya provee estas clases.


<dependency>
    <groupid>javax.servlet</groupid>
    <artifactid>servlet-api</artifactid>
    <version>2.4</version>
    <scope>provided</scope>
</dependency>

Para más información sobre los scopes de las dependencias, se puede consultar esta referencia.

Tardé un rato en darme cuenta de que el problema lo tenía al incluir la dependencia de jabsorb. Y era jabsorb el que me traía esas dependencias transitivas que me estaban molestando. Al abrir el pom de jabsorb vi que en efecto las dependencias ahí estaban:


<!-- Test dependencies -->
<dependency>
    <groupid>org.mortbay.jetty</groupid>
    <artifactid>jetty</artifactid>
    <version>6.1.6</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupid>org.mortbay.jetty</groupid>
    <artifactid>jsp-2.1</artifactid>
    <version>6.1.6</version>
</dependency>

La primera no molestaba porque tenía el scope de test, así que no iba a ser incluída en el war final, pero la segunda era la conflictiva jsp-2.1 del servidor jetty, la que terminaba trayendo jsp-api-2.1 mediante otra dependencia transitiva y terminaba reemplazando la implementación de jasper, el compilador de JSPs, de JBoss Web por la implementación de Jetty.

Solución: remover la dependencia jsp-2.1.

Una forma de implementar la Solución: Agregándole el scope provided o test a la dependencia de jsp-2.1 de jetty en el pom de jabsorb:


<dependency>
    <groupid>org.mortbay.jetty</groupid>
    <artifactid>jsp-2.1</artifactid>
    <version>6.1.6</version>
    <scope>provided</scope>
</dependency>

Subimos de vuelta el pom y el jar al repositorio de maven y chau problema.

Pero no siempre podemos modificar de esta forma el pom de la dependencia. Quizá la solución más sana sería la segunda:

Otra forma de implementar la Solución: Al incluir la dependencia de jabsorb, excluir la dependencia transitiva de jsp-2.1, de la siguiente forma:


<dependency>
    <groupid>org.jabsorb</groupid>
    <artifactid>jabsorb</artifactid>
    <version>1.3</version>    
    <exclusions>
        <exclusion>
            <groupid>org.mortbay.jetty</groupid>
            <artifactid>jsp-2.1</artifactid>
        </exclusion>
 </exclusions>        
</dependency>

Referencias:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
http://docs.codehaus.org/display/MAVENUSER/Deploying+3rd+Party+Jars+With+WebDAV

HOWTO: Testear la funcionalidad de un WebService con SOAPUI

2009-01-25T15:23:00.000-08:00

Versiones utilizadas: soapui 2.5
Pagina de internet: http://www.soapui.org/index.html
Servicio de feriados: http://www.mininterior.gov.ar/servicio/wsferiados.asp

HowTo: Testear la funcionalidad de un WebService con SOAPUI

Objetivo: SoapUI es una interfaz gráfica escrita en java que nos permite testear WebServices y nos facilita la generación de clientes de WebService. El objetivo de este post es testear la funcionalidad de un WebService en este caso será el servicio de feriados del Ministerio del Interior.

Paso 1: Iniciar la aplicación mediante el script soapui.sh que se encuentra en la carpeta bin
Paso 2: Crear un nuevo proyecto

Paso 3: Seleccionar el archivo wsdl del servicio. La opción "Create sample request for all operations? " nos creará request para todas las operaciones incluidas en el wsdl.

feriados.wsdl



<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions name="MyService" targetNamespace="http://tempuri.org/"
 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
 xmlns:tns="http://tempuri.org/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
 xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract"
 xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
 xmlns:wsa10="http://www.w3.org/2005/08/addressing" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex">
 <wsdl:types>
  <xsd:schema targetNamespace="http://tempuri.org/Imports">
   <xsd:import
    schemaLocation="http://webservices.mininterior.gov.ar/Feriados/Service.svc?xsd=xsd0"
    namespace="http://tempuri.org/" />
   <xsd:import
    schemaLocation="http://webservices.mininterior.gov.ar/Feriados/Service.svc?xsd=xsd1"
    namespace="http://schemas.microsoft.com/2003/10/Serialization/" />
   <xsd:import
    schemaLocation="http://webservices.mininterior.gov.ar/Feriados/Service.svc?xsd=xsd2"
    namespace="http://tempuri.org/FeriadoDS.xsd" />
   <xsd:import
    schemaLocation="http://webservices.mininterior.gov.ar/Feriados/Service.svc?xsd=xsd3" />
  </xsd:schema>
 </wsdl:types>
 <wsdl:message name="IMyService_FeriadosEntreFechas_InputMessage">
  <wsdl:part name="parameters" element="tns:FeriadosEntreFechas" />
 </wsdl:message>
 <wsdl:message name="IMyService_FeriadosEntreFechas_OutputMessage">
  <wsdl:part name="parameters" element="tns:FeriadosEntreFechasResponse" />
 </wsdl:message>
 <wsdl:message name="IMyService_FeriadosEntreFechasAsXml_InputMessage">
  <wsdl:part name="parameters" element="tns:FeriadosEntreFechasAsXml" />
 </wsdl:message>
 <wsdl:message name="IMyService_FeriadosEntreFechasAsXml_OutputMessage">
  <wsdl:part name="parameters" element="tns:FeriadosEntreFechasAsXmlResponse" />
 </wsdl:message>
 <wsdl:portType name="IMyService">
  <wsdl:operation name="FeriadosEntreFechas">
   <wsdl:input wsaw:Action="http://tempuri.org/IMyService/FeriadosEntreFechas"
    message="tns:IMyService_FeriadosEntreFechas_InputMessage" />
   <wsdl:output
    wsaw:Action="http://tempuri.org/IMyService/FeriadosEntreFechasResponse"
    message="tns:IMyService_FeriadosEntreFechas_OutputMessage" />
  </wsdl:operation>
  <wsdl:operation name="FeriadosEntreFechasAsXml">
   <wsdl:input wsaw:Action="http://tempuri.org/IMyService/FeriadosEntreFechasAsXml"
    message="tns:IMyService_FeriadosEntreFechasAsXml_InputMessage" />
   <wsdl:output
    wsaw:Action="http://tempuri.org/IMyService/FeriadosEntreFechasAsXmlResponse"
    message="tns:IMyService_FeriadosEntreFechasAsXml_OutputMessage" />
  </wsdl:operation>
 </wsdl:portType>
 <wsdl:binding name="BasicHttpBinding_IMyService" type="tns:IMyService">
  <soap:binding transport="http://schemas.xmlsoap.org/soap/http" />
  <wsdl:operation name="FeriadosEntreFechas">
   <soap:operation soapAction="http://tempuri.org/IMyService/FeriadosEntreFechas"
    style="document" />
   <wsdl:input>
    <soap:body use="literal" />
   </wsdl:input>
   <wsdl:output>
    <soap:body use="literal" />
   </wsdl:output>
  </wsdl:operation>
  <wsdl:operation name="FeriadosEntreFechasAsXml">
   <soap:operation
    soapAction="http://tempuri.org/IMyService/FeriadosEntreFechasAsXml"
    style="document" />
   <wsdl:input>
    <soap:body use="literal" />
   </wsdl:input>
   <wsdl:output>
    <soap:body use="literal" />
   </wsdl:output>
  </wsdl:operation>
 </wsdl:binding>
 <wsdl:service name="MyService">
  <wsdl:port name="BasicHttpBinding_IMyService" binding="tns:BasicHttpBinding_IMyService">
   <soap:address
    location="http://webservices.mininterior.gov.ar/Feriados/Service.svc" />
  </wsdl:port>
 </wsdl:service>
</wsdl:definitions>

Paso 4: Hacer doble click sobre Request 1, que se trata del request generado automáticamente para la operación feriadosEntreFechas. Esto nos abrirá el editor de request.

Paso 5: Para pasarle parametros al servicio deben reemplazar los signos de interrogación.
Paso 6: En este caso, tenemos que ingresar atributos de tipo datetime, para ingresar el rango de fechas de los feriados que necesitamos. Es importante respetar el formato para que no tengamos una excepcion de transformacion. Para ejecutar la invocacion al webservice hacemos click sobre el botón verde de play.

Paso 7: En la ventana de al lado se puede visualizar el resultado de la invocación del webservice.

HowTo: Invocar un Workflow desde otro Workflow usando Process-States con jbpm

2008-12-26T03:36:00.000-08:00

Versiones Utilizadas: jbpm 3.3.0-GA

Según la Wikipedia: "Se llama Business Process Management (BPM) a la metodología empresarial cuyo objetivo es mejorar la eficiencia a través de la gestión sistemática de los procesos de negocio, que se deben modelar, automatizar, integrar, monitorizar y optimizar de forma continua."

jBPM es la implementación BPM de JBoss. Como toda implementación de BPM, sirve para modelar procesos. Si bien lo ideal sería que estos procesos puedan modelarse de forma visual, jBPM no cuenta aún con muy buen soporte para esto. El único modelador de procesos visual oficial es el GPD, un plug-in para Eclipse que sinceramente me ha dado muchos dolores de cabeza (porque es bastante anti-user-friendly y porque está bastante buggeado). Pero GPD no provee una solución gráfica para las vastas funcionalidades que provee el lenguaje jPDL (lenguaje basado en XML), que jbpm implementa, con lo cual, cuando alguien tiene que verse obligado a modelar un workflow un poco fuera de lo común (como me vi obligado yo), tiene que sí o sí tocar el XML.

No voy a detenerme en la teoría de jBPM, ya que de eso se ha encargado Salaboy que ha dedicado (y sigue dedicando) muchísimos posts cla ros y concretos a esta tecnología. Aconsejo fuertemente leer todos estos posts si se quiere o necesita dar los primeros pasos en jBPM. También los puede ayudar la guía de usuario oficial del sitio de JBoss. El motor y la suite completa de jBPM se puede descargar de la página de descarga oficial.

HowTo: Invocar un Workflow desde otro Workflow usando Process-States.

Descripción: El objetivo es usar el nodo Process-State para ejecutar un sub-workflow. Esto puede resultar muy útil para la reutilización de secuencias de procesos, de la misma forma que en programación se puede reutilizar una subrutina, función o método.

Objetivo: Dados dos workflows: WorkflowA y WorkflowB, se desea que el WorkflowB invoque al WorkflowA en el medio de su ejecución, usando un nodo del tipo process-state.

WorkflowA:

ProcessDefinition.xml:

<?xml version="1.0" encoding="UTF- 8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2"  name="WorkflowA">

    <start-state name="start-state1">
      <transition to="node1"></transition>
    </start-state>

    <node name="node1">
      <action class="com.sample.action.Action1" name="action1"></action>
      <transition to="end-state1"></transition>
    </node>

    <end-state name="end-state1"></end-state>
</process-definition>

WorkflowB:

ProcessDefinition.xml:

<?xml version="1.0" encoding="UTF- 8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2"  name="WorkflowB">

    <start-state name="start-state1">
      <transition to="node1"></transition>
    </start-state>

    <node name="node1">
   
   <action class="com.sample.action.Action2" name="action2"></action>
      <transition to="process-state1"></transition>
    </node>

   <process-statename="process-state1">
      <sub-process name="WorkflowB" />
      <variable name="a" access="read,write" mapped-name= "aa" />
      <variable name="b" access="read" mapped-name= "bb" />
      <transitionto="node2"><transition>
    </process-state>

    <node name="node2">
      <action class="com.sample.action.Action3"name="action3"></action>
      <transition to="end-state1"></transition>
    </node>

    <end-state name="end-state1"></end-state>
</process-definition>

Invocación: A continuación, un ejemplo de un código cliente que podría funcionar en una aplicación de consola stand-alone de JavaSE:


// Se leen los XML de processDefinition

ProcessDefinition processDef = ProcessDefinition.parseXmlResource("WorkflowB/processdefinition.xml");
ProcessDefinition subProcessDefinition =
ProcessDefinition.parseXmlResource("WorkflowA/processdefinition.xml");


// Se obtiene el nodo del tipo process-state del WorkflowB
// y se le setea la definición del WorkflowA

ProcessState processState = (ProcessState) processDef.getNode("process-state1");
processState.setSubProcessDefinition(subProcessDefinition);


// Se instancia el WorkflowB
ProcessInstance processInstance = new ProcessInstance(processDef);


// Se setean en el contexto tres variables
ContextInstance context = processInstance.getContextInstance();

context.setVariable("a", "Variable a compartida");
context.setVariable("b", new Integer(15));

context.setVariable("redondo", "PATRICIO REY Y SUS REDONDITOS DE RICOTA");

// Se larga la corrida del WorkflowB

System.out.println("--- Inicio del workflow! ---");
processInstance.signal();
System.out.println("--- Fin del workflow! ---");


// Se imprime el estado de las variables del contexto
System.out.println(context.getVariable("a"));

System.out.println(context.getVariable("b"));
System.out.println(context.getVariable("redondo"));

Para demostrar cómo funciona el pasaje de variables de contexto en un process-state definí tres Actions (clases que implementan la interfaz ActionHandler de jbpm y el método abstracto execute). El más interesante es el Action1, que es el que se ejecuta en el WorkflowA (el sub-workflow):


@Override
public void execute(ExecutionContext context) throws Exception {

   System.out.println("ACTION 1 FROM NODE 1");

   // Se imprimen las variables

   System.out.println(context.getVariable("aa"));
   System.out.println(context.getVariable("bb"));
   System.out.println(context.getVariable("redondo"));


   // Se modifican aa y bb
   String aa = (String) context.getVariable("aa");

   aa = "Variable modificada por subworkflow A";
   context.setVariable("aa", aa);


   Integer bb = (Integer) context.getVariable("bb");
   bb += 10;

   context.setVariable("bb", bb);

   System.out.println(context.getVariable("aa"));

   System.out.println(context.getVariable("bb"));

   context.leaveNode();
}

Los demás Action lo único que hacen es imprimir en la consola un mensaje para indicar que se están ejecutando.

Salida: Al ejecutar este código de ejemplo por consola, obtenemos la siguiente salida:

--- Inicio del workflow! ---
ACTION 2 FROM NODE 2
ACTION 1 FROM NODE 1
Variable a compartida
15
null
Variable modificada por subworkflow A
25
ACTION 3 FROM NODE 3
--- Fin del workflow! ---
Variable modificada por subworkflow A
15
PATRICIO REY Y SUS REDONDITOS DE RICOTA

Lo interesante de ver acá es que el sub-workflow se ejecutó y que, de las tres variables de contexto que había ("a", "b" y "redondo"), la primera fue modificada por el WorkflowA (esto fue posible ya que tenía acceso de lectura y escritura), la segunda fue recibida por el WorkflowA pero no fue modificada (el valor se perdió al terminar la ejecución del workflow porque era de sólo lectura) y la tercera variable, el String "redondo", conservó su valor y no pudo ser accedida desde el WorkflowA (noten que el valor dentro del Action1 era null; la variable no fue copiada del contexto del WorkflowB al contexto del WorkflowA).

Referencias:
http://docs.jboss.com/jbpm/v3.2/userguide/html/processmodelling.html#processcomposition
http://salaboy.wordpress.com/category/jboss-jbpm/
http://kickjava.com/src/org/jbpm/graph/node/ProcessStateTest.java.htm
http://www.workflowpatterns.com/
http://docs.jboss.com/jbpm/v3/demos/movies/jbpm-overview.htm
http://docs.jboss.org/jbpm/v3/javadoc/

HowTo: Cerrar ModalPanel cuando no existen mensajes de error.

2008-12-16T04:22:00.000-08:00

Versiones Utilizadas: RichFaces 3.2.2

El Modal Panel es un componente de RichFaces que básicamente es una ventana que se superpone a la ventana principal. La ventana principal se desactiva mientras este el modal panel en uso.

Aquí pueden ver la documentación oficial de RichFaces:
Guia para programadores.
RichFaces Live Demo (Ejemplos de ModalPanel)

HowTo: Cerrar ModalPanel cuando no existen mensajes de error.

Descripción: El objetivo es tener un modal panel con un botón que ejecute una acción. Una vez ejecutada la acción, si no existen errores en el FacesContext , el Modal Panel deberá cerrarse automáticamente.

Por ejemplo tenemos dos métodos en un controller, uno genera un error y el otro no.


public void executeAction(){
 log.info("execute action");
 String errorMessage = "Ocurrio un error en executeAction";
 FacesMessage message = new
FacesMessage(FacesMessage.SEVERITY_ERROR,errorMessage,errorMessage);
 FacesContext.getCurrentInstance().addMessage("actionform:executeactionbutton",
message);
    }

    public void executeActionTwo(){
 log.info("execute action two");
    }

Habra tres botones, uno que ejecuta el método que agrega un error al FacesContext, otro que no hace nada y un tercero que se usa para cerrar el modal panel:



<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:s="http://jboss.com/products/seam/taglib"
xmlns:rich="http://richfaces.org/rich"
xmlns:a4j="http://richfaces.org/a4j">
<body>

<ui:composition template="/template.xhtml">
<ui:define name="body">

 <table>
  <tr>
   <td class="contTitulo"><h:outputText value="Demo RichFaces"/></td>
  </tr>
 </table>
 <div class="hrdot"><img src="images/1x1.gif" /></div>

 <!-- Boton que abre el modal panel -->
 <h:outputLink value="#" id="link">
  Abrir Modal Panel
  <rich:componentControl for="panel" attachTo="link" operation="show" event="onclick"/>
 </h:outputLink>

 <!-- Codigo Modal Panel -->
 <rich:modalPanel id="panel" width="500" height="400">
  <f:facet name="header">
   <h:panelGroup><h:outputText value="Modal Panel"></h:outputText></h:panelGroup>
  </f:facet>
  <h:outputText value="Al hacer click sobre el botón se ejecutara la acción, sino existen errores el modal panel se ocultará. Sino mostrará    el error"></h:outputText>
  <a4j:form id="actionform">
   <table>
   <tr>
    <td>
     <a4j:commandButton id="executeactionbutton" value="Ejecutar accion Con Error" action="#{userctrl.executeAction}"       oncomplete="if (#{empty facesContext.maximumSeverity}) #{rich:component('panel')}.hide();"/>
     <rich:message for="executeactionbutton"/>
    </td>
   </tr>
   <tr>
    <td>
     <a4j:commandButton value="Ejecutar accion Sin error " action="#{userctrl.executeActionTwo}" 
      oncomplete="if(#{empty facesContext.maximumSeverity}) #{rich:component('panel')}.hide();"/>
    </td>
   </tr>
   <tr>
    <td>
     <a4j:commandButton value="Cerrar" oncomplete="#{rich:component('panel')}.hide();"/>
    </td>
   </tr>
   </table>
  </a4j:form>
 </rich:modalPanel>
</ui:define>
</ui:composition>
</body>
</html>

Lo importante de este código es la linea oncomplete="if (#{empty facesContext.maximumSeverity}) #{rich:component('panel')}.hide();".

Otras soluciones encontradas:
http://jboss.com/index.html?module=bb&op=viewtopic&t=134933
http://www.martinahrer.at/blog/2008/03/05/keep-rich-faces-modal-panel-open-when-form-validation-errors-occur/
http://www.jboss.org/community/docs/DOC-11435
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061517

Jep - Parser Java de Expresiones Matematicas

2008-11-16T06:45:00.000-08:00

En un trabajo practico de la Facultad me pedían la parametrización de una función, tenia dos opciones crear el parser o buscar alguna librería que lo tuviera encapsulado. Optamos por buscar la librería y asi fue como, a través, de un compañero conocí JEP. La pagina oficial es http://www.singularsys.com/jep/.

Este parser es muy sencillo de utilizar, al menos para lo que yo necesitaba, sin embargo se pueden crear funciones complejas con muchas variables y a su vez con muchas funciones, en este post usaremos de ejemplo un función con una variable.

Los operadores Aritméticos que se pueden utilizar son:

+ Suma
- Resta
/ División
* Multiplicacion
% Modulo
^ Potencia

Pero también soporta operadores lógicos por lo que dispondremos del && (AND), || (OR), ! (NOT), >, <, >=, <=, == (EQUALS), entre otros. Este parser a su vez dispone de funciones standart para ser utilizadas, en el código tendremos que habilitarlas con la linea jep.addStandardFunctions();

sin(x): Seno
cos(x): Coseno
tan(x): Tangente
asin(x): ArcoSeno
acos(x): ArcoCoseno
atan(x): ArcoTangente
sinh(x): Seno Hiperbolico
cosh(x): Coseno Hiperbolico
tanh(x): Tangente Hiperbolica
ln(x): Logaritmo Natura
log(x): Logaritmo en base 10
lg(x): Logaritmo en base 2
exp(x): exponencial

Para habilitar las constantes debemos agregar al codigo jep.addStandardConstants()

La función que vamos a utilizar es 80 * sin(-((x/40)^(1/2))) para que no nos tire una excepción org.nfunk.jep.ParseException: Syntax Error (implicit multiplication not enabled) provocado por al falta del operador multiplicación entre el signo menos y el valor que se calculo entre los paréntesis, podemos cambiar la función a 80 * sin((-1) * ((x/40)^(1/2))) o habilitar la multiplicación explicita con jep.setImplicitMul(true);.


package com.blogspot.tecnologiasjava.test;

import org.nfunk.jep.JEP;
import org.nfunk.jep.Node;
import org.nfunk.jep.ParseException;
importorg.nfunk.jep.function.Sine;

public class Test {

    private static String funcion ="80*sin(-((x/40)^(1/2)))";
   
    public static void main(String[] args) {
   
       JEP jep =new JEP();
       jep.setImplicitMul(true);
       jep.addStandardFunctions();
       
        /** Le damos un valor a la variable */
       jep.addVariable("x", 5.0);
       double resultado =0.0;
       try {
           /** Parseamos la funcion */
           Node expresion = jep.parse(funcion);
           /** Evaluamos la expresion */
           resultado = (Double)jep.evaluate(expresion);
        } catch (ParseException e) {
           System.out.println("Error al parsear la funcion :"+funcion);
           e.printStackTrace();
        }
       System.out.println(resultado);
    }
}

¿Por qué un corrector ortográfico en Eclipse?

2008-10-21T15:02:00.000-07:00

Ya todos habrán visto o se habrán enterado que las últimas versiones de Eclipse vienen con un corrector ortográfico al mejor estilo procesador de texto, que al escribir los comentarios va subrayando las palabras mal escritas, del mismo modo que se subraya lo que no compila.

Lo primero que pensé cuando lo vi fue: "Qué porquería! Cómo lo desactivo?", como le habrá pasado a la mayoría de los programadores imagino. Como si no fuera pesada ya la compilación on the fly (que es bastante útil, pero si tenemos un buen fierro), se le agrega otro proceso más que corre en background inspeccionando los comentarios.

Creo que el primer impulso de cualquier programador es desactivarlo. Y eso es fácil. Vamos a: Window -> Preferences -> General -> Editors -> Text Editors -> Spelling y desde aquí podemos personalizar a gusto el corrector o inhabilitarlo por completo.

Ahora, reflexionando un poco, y dejando de lado nuestros viejos instintos primitivos de sentarse a programar todo un método gigante de una, sin respirar, sin diseño ni nada. ¿Por qué un corrector ortográfico en Eclipse? ¿Hacemos bien en desactivarlo?

En el caso en que tengamos 1 Gb de RAM (o menos) yo opino que sí. Lo mismo si estamos escribiendo comentarios en castellano. ¿De qué sirve un corrector que subraya todas las palabras porque están en otro idioma?

Pero si estamos escribiendo código en inglés, con comentarios en inglés, y tenemos una máquina que se lo banque. ¿Por qué no?

Si algo nos están enseñando las nuevas metodologías ágiles de desarrollo es que la escritura de código es un arte iterativo. Al igual que un escultor, vamos refactoreando nuestro código, vamos perfeccionándolo, minimizándolo, clarificándolo.

Un buen programador es aquel que escribe código legible, eficiente, reutilizable. Javadoc, por ejemplo, nos provee la posibilidad de incluir la documentación en el código. Y si escribimos buena documentación, es mejor que no tenga errores ortográficos.

Yo creo que por ese lado viene la idea de la gente de Eclipse de incorporar un corrector ortográfico en un IDE de programación. Las metodologías ágiles fomentan la escritura de documentación dentro del mismo código.

Por otro lado, también tenemos filosofías como la de Domain-Driven Design, que fomentan escribir un código verboso, muy claro y orientado al dominio. Mediante el lenguaje ubicuo podemos escribir código que a la vez sirva como documentación. Los nombres de los atributos, de las clases y de los servicios pueden ser escogidos para que un experto de dominio sea capaz de comprender a alto nivel como funciona la aplicación.

Todo tiende a que, como programadores, tengamos que switchear lo menos posible entre un documento de Word y el IDE. ¿Para qué? Si podemos tener todo en un lugar solo. A esto apunta la decisión de un corrector ortográfico en los comentarios.

Igual, cada día creo más que es mejor un código verboso, con claros y efectivos unit tests, que líneas y líneas de comentarios o de Javadoc para explicar que estamos recorriendo un array o estamos aumentando el valor de una variable, o peor: para explicar qué hace un método y qué tiene que recibir y devolver, cuando la misma firma, con su nombre, sus parámetros y su tipo de retorno ya lo indica. Un código claro debería entenderse por sí solo.

findJAR.com

2008-10-09T18:57:00.000-07:00

Uno de los obstáculos más comunes para un programador que recién comienza a adentrarse en el mundo de Java es la resolución de dependencias. La vida sería mucho más sencilla si cada import se resolviera solo (por la virtual machine, el compilador o quien sea), si alguna herramienta, aumáticamente, buscara (en algún lado) el archivo JAR donde vive esa clase (ese .class) que estamos tratando de importar, y se agregara solito al classpath sin problemas.

Hay algunos IDEs como Eclipse o NetBeans que nos ayudan un poco en esta tarea, o tecnologías modernas como Maven2, que día a día gana más adeptos.

Pero la verdad es que a la hora de importar una clase que no conocemos, ni tenemos la somera idea de dónde empezar a buscar, puede traernos un pequeño dolor de cabeza.

Por eso hoy me puse bastante contento cuando conocí esta página por medio de un compañero de trabajo. Se llama findJAR y lo que hace justamente es, a partir del nombre de una clase o paquete, busca en su extensa base de datos para contarnos dónde podemos encontrar alguna implementación de esa bendita clase que estamos buscando.

Además, como si no fuera ya suficiente utilidad el que podamos localizar el nombre del JAR que estábamos buscando, la página nos da información sobre la URL de donde viene la librería, las demás clases y paquetes que se pueden encontrar ahí dentro, y lo mejor: el link para descargarnos el JAR desde ibiblio, uno de los repositorios de mirrors más populares que usan muchas aplicaciones y proyectos, como Maven o Maven2, por ejemplo.

Sin lugar a dudas, una herramienta fundamental para el trabajo diario, digna de adjuntar a mis Bookmarks.

Desarrollo de un EJB 3.0 en Eclipse

2008-09-28T10:05:00.000-07:00

Objetivo

A) Desarrollar un EJB 3.0 en eclipse.
B) Desplegar un EJB en JBOSS
C) Desarrollar un cliente para invocar un metodo del EJB.

Versiones utilizadas:

Eclipse 3.4 para JavaEE con los plugins de Jboss Tools 2.1.2 (http://www.jboss.org/tools/) Jboss 4.2.3

A) Desarrollar un EJB 3.0 en eclipse.

Primero creamos un proyecto EJB Project. File/New, seleccionamos en el desplegable Others. Ahora buscamos EJB/EJB Project. Al proyecto lo llamamos EJB3-Project.

Ahora vamos a crear un Session Bean , en este caso sera Stataless y Remoto. Vamos a File/New/EJB/

El Session Bean se llamara HelloWorldBean y la interface HelloWorld. Aceptamos.

Podemos observar que al proyecto se agregaron las dos clases, pero tenemos algunos de paquetes. Esto es porque tenemos que agregarle la libreria de jboss. Boton secundario sobre el proyecto, Build Path, Configure Build Path, pesta;a Libraries. Hacemos click sobre Add y seleccionamos Jboss EJB3 Libraries.

Hacemos click en Next. Si todavía no definieron a Jboss como un Server, en este paso se les solicitara que lo creen. Hacemos click en CREATE A JBOSS SERVER. En nuestro caso estamos trabajando con la version 4.2 de JBoss, por lo que seleccionamos en el listado JBoss AS 4.2 y en Server Name ingresamos JBoss4.2

En la pantalla siguiente ingresamos la ruta de nuestro JBoss y por ahora dejamos seleccionado Default en Configuration.

En la pantalla siguiente se nos pide la clave y password de JMX-Console. Ingresen admin,admin que son los valores por defecto. Hacemos click en finish. Volvimos al punto de la seleccion de la librería de Jboss. Ahora hacemos click sobre JBoss 4.2 Server y hacemos click en Finish nuevamente. Y para finalizar OK.

Ahora Agregamos el método getHelloWorld a nuestras clases. Estas son las clases finales del bean.



import javax.ejb.Stateless;
 
/**
 * Session Bean implementation class HelloWorldBean

 */
@Stateless
public class HelloWorldBean implements HelloWorld {
 
    public String getHelloWorld(){

        return "Hola EJB 3.0";
    }
    
 
}
 
package com.blogspot.tecnologiasjava.ejb;
import javax.ejb.Remote;

 
@Remote
public interface HelloWorld {
    
    public String getHelloWorld();

B) Desplegar un EJB en JBOSS

Para desplegar el EJB HelloWord en JBoss, hacemos click con el botón secundario del mouse sobre el proyecto. Seleccionamos Run As/Run On Server. Se nos pedira seleccionar el server donde queremos desplegarlo. Seleccionamos JBoss4.2 Server que es nuestra única opción por ahora :P. Hacemos click sobre Finish.

En la consola podemos ver el log de Jboss. Afortunadamente nuestro EJB se desplegó correctamente.

3) Desarrollar un cliente para invocar un método del EJB.

Ahora haremos un sencillo cliente que buscara el EJB mediante JNDI e invocara el método getHelloWorld del Bean.

Primero creamos un nuevo proyecto Java en este caso lo llamamos TestEJB
Agregamos a este proyecto el proyecto anterior. Click con el botón secundario sobre el proyecto. Seleccionar Java Build Path. En la pestaña Projects hacer click sobre Add y seleccionar el proyecto EJB3-Project.
También tenemos que agregar jbossall-client.jar que esta en la carpeta de instalación de jboss/client/

Creamos una clase llamada Test por ejemplo con el siguiente código.



<package com.blogspot.tecnologiasjava.test;

import java.util.Properties;
import javax.naming.Context;

import javax.naming.InitialContext;
import javax.naming.NamingException;
import com.blogspot.tecnologiasjava.ejb.HelloWorld;

 
public class Test {


    public static void main(String[] args) throws Exception {
        Properties properties = new Properties();

        properties.put("java.naming.factory.initial","org.jnp.interfaces.NamingContextFactory");
        properties.put("java.naming.factory.url.pkgs","=org.jboss.naming:org.jnp.interfaces");
        properties.put("java.naming.provider.url", "localhost:1099");

        Context ctx = new InitialContext(properties);
        HelloWorld hello = null;
        try {

            hello = (HelloWorld) ctx.lookup("HelloWorldBean/remote");
        } catch (NamingException e) {

            e.printStackTrace();
        }
        System.out.println(hello.getHelloWorld());

    }

}

Al ejecutar el test deberíamos ver el mensaje HOLA EJB 3.0.

Plugin de Maven2 para Sysdeo

2008-09-23T20:54:00.000-07:00

En el post anterior de HelloServlet Web Application con Maven2 y Eclipse, mencioné al pasar que existía un plugin para Maven (un Mojo) que ya resolvía el problema que yo quería resolver. El plugin es de Codehaus, un espacio colaborativo donde se construyen proyectos open source, y se llama sysdeo-tomcat-maven-plugin. Su uso es realmente muy sencillo y, si lo que quieren es ahorrarse un dolor de cabeza, recomiendo que lo usen.

Como cualquier mojo de Maven, se descarga solito la primera vez que lo invocamos.

Paso primero, abrimos una consola y hacemos lo mismo que hicimos en el post anterior para crear un proyecto web vacío. Escribimos:

$ mvn archetype:create -DgroupId=com.blogspot.tecnologiasjava.helloservletmaven2 -DartifactId=HelloServletMaven2 -DarchetypeArtifactId=maven-archetype-webapp

Recuerden que el archetype maven-archetype-webapp es el que ya nos genera un proyecto web con sus correspondientes carpetas de /src/main/java, la ruta por default para tirar el código, /src/main/resources, la ruta por default para tirar los recursos, y /src/main/webapp, que servirá como root de la aplicación web, con un index.jsp y una carpeta WEB-INF con su web.xml para registrar servlets.

Lo siguiente que tenemos que hacer es convertir el proyecto a un proyecto Eclipse. Para eso, como ya vimos, ejecutamos:

mvn eclipse:eclipse

Esto nos generará el .project y el .classpath que el IDE necesita para importar el proyecto como si fuera propio.

Pero momento! No importaremos el proyecto todavía. Nos falta hacer una cosa más.

Abrimos el pom.xml y en el tag <build> debajo de <finalname> agregamos lo siguiente:

  <plugins>
      <plugin>
          <groupId>org.codehaus.mojo</groupId>
          <artifactId>sysdeo-tomcat-maven-plugin</artifactId>
          <version>1.1</version>
      </plugin>
  </plugins>

Este tag lo que hace es agregar la dependencia del plugin de Codehaus al proyecto. Cuando invoquemos al mojo, que será en el próximo paso, las dependencias se descargarán en nuestro repositorio local y podremos hacer uso del mismo.

En la consola tipeamos:

mvn sysdeo-tomcat:generate

Con esto lo que logramos es que se genere el .tomcatplugin que Sysdeo necesita para reconocer al proyecto como un proyecto Tomcat, y que automáticamente agregue lo necesario en el .project para habilitar el menú de Tomcat en el Eclipse.

Ahora sí, importamos el proyecto en Eclipse y gualá! Si vamos a las propiedades del proyecto -> Tomcat, vemos que efectivamente es un proyecto Tomcat y, las rutas que en el post anterior con mucha dedicación configuramos, aquí ya están correctas.

HelloServlet Web Application con Maven2 y Eclipse

2008-09-21T18:11:00.000-07:00

Apache Maven es una herramienta muy poderosa de Apache, que sirve para buildear proyectos hechos en Java. Un momento! ¿¿Para buildear?? ¿Apache ya no había lanzado Apache Ant para eso?

La diferencia que hay entre Maven y Ant es tan grande que hasta casi parece que provienen de dos diferentes paradigmas. Ant es una simple herramienta para buildear. No es más que un make multiplataforma, procedural, como cualquier proceso batch. Tranquilamente el build.xml que tenemos que escribir con Ant, lo podríamos escribir con un script de Bash, de DOS, de perl o de python. La gran diferencia es que Maven introduce el concepto de POM (Project Object Maven) y, con él, muchas funcionalidades que Ant no intenta ni intentará cubrir, como resolución automática de dependencias, armado de archetypes (esqueletos de proyectos para distintas plataformas), herramientas para estadísticas, administración de proyectos y un largo etcétera.

Maven es un pequeño core que por sí solo no hace nada, pero al comenzar a usarlo empezará a descargar todos los plugins que lo hacen extremadamente poderoso e invencible.

Sí, ya sé, ésa es una desventaja... Dudo que Maven pueda servir de mucho sin una conexión a Internet.

Lo que me propongo en este post, es lograr crear un proyecto web con Maven, utilizando uno de estos archetypes que mencioné, y luego integrar este proyecto con Eclipse y Sysdeo, el plugin de Apache Tomcat. A pesar de que ya existe un plugin para Maven que ya resuelve lo que yo estoy a punto de explicar y que todavía no he tenido oportunidad de investigar, creo que el siguiente ejemplo puede resultar muy útil para el que no conoce nada de Maven.

Para la realización de este ejemplo utilicé:

JDK 1.6
Apache Tomcat 6.0.18
Apache Maven 2.0.9
Eclipse 3.4.0
TomcatPluginV321 (Sysdeo)

Creando un HelloServlet con Maven paso a paso

Paso 1 - Crear un proyecto web vacío con Maven:

El primer paso consiste en abrir una consola, pararnos sobre el directorio donde tenemos nuestro workspace de Eclipse y tipear nuestro primer comando Maven:

$ mvn archetype:create -DgroupId=com.blogspot.tecnologiasjava.helloservletmaven -DartifactId=HelloServletMaven -DarchetypeArtifactId=maven-archetype-webapp
El archetype que usamos se llama maven-archetype-webapp. El resultado exitoso de este comando es un proyecto Maven nuevo, que cuelga sobre el directorio del que lo invocamos, con el nombre HelloServletMaven y con la estructura de carpetas necesarias para desplegarlo en un Tomcat.

Paso 2 - Convertir el proyecto en un proyecto de Eclipse:

Maven tiene un plugin que sirve para convertir cualquier proyecto en un proyecto para Eclipse. Simplemente lo que tenemos que hacer es tipear:

$ mvn eclipse:eclipse

Habrán notado que si es la primera vez que utilizan Maven cada comando desencadena varias descargas de distintos repositorios, algunas pueden tardar su buen tiempo. Esto es porque Maven descarga todo lo que necesita para ejecutar el comando o se fija si hubo alguna actualización.

Paso 3 - Importar el proyecto con Eclipse:

Este paso consiste simplemente en importar el proyecto en Eclipse: Import --> Existing Project into Workspace. Una vez importado el proyecto, veremos que hay algunas rutas en el classpath que no pueden resolverse. Si pasa esto, seguramente es porque no tenemos configurada la variable M2_REPO en el classpath del Eclipse. Para registrarla vamos a Windows -> Preferences y allí elegimos Java -> Build Path -> Classpath Variables.

Hacemos click en New y cargamos la variable M2_REPO con la ruta del repositorio local de Maven2, que seguramente es $HOME/.m2/repository, si trabajan con Linux.

Cuando le demos aceptar, Eclipse nos preguntará si queremos re-buildear. Por supuesto le contestamos que sí. Y ya está! Problemas de buildeo solucionados.

Maven cuenta con dos tipos de repositorios: los locales y los externos o remotos. En estos repositorios viven miles y miles de jars que Maven se descargará para resolver automáticamente las dependencias que tenga el proyecto. Para más información sobre los repositorios: http://maven.apache.org/guides/introduction/introduction-to-repositories.html.

Paso 4 - Buildear con Maven:

Para buildear con Maven, escribimos en la consola:

$ mvn clean install

Como siempre, veremos que se bajan varios archivos. Habrá que tener paciencia.

Al terminar notaremos que nos generó una carpeta target en el root del proyecto y en la que dentro, entre otras cosas, vive un archivo llamado HelloServletMaven.war. Este HelloServletMaven.war puede desplegarse en el Tomcat como cualquier archivo war y va a funcionar perfecto. Pero no es eso lo que queremos por ahora. Lo que queremos es desplegar la aplicación con el mismo plugin de Eclipse, Sysdeo.

Paso 5 - Convertir el Proyecto en un Proyecto Tomcat:

En Eclipse, botón derecho sobre el proyecto -> Properties. Vamos a donde dice Tomcat y, en la solapa General, clickeamos en Is a Tomcat Project. Luego, en Subdirectory to set as web application root (optional), seteamos la ruta que el Maven usa en su archetype como root de la web-app: /src/main/webapp (la ruta es relativa al root del proyecto).

Paso 6 - Levantar el Hello World:

Levantamos el Tomcat con el plugin de Sisdeo (start tomcat) y, para probar que vamos por buen camino, abrimos el browser y vamos a http://localhost:8080/HelloServletMaven/ (asumiendo que nuestro Tomcat esté escuchando en el puerto 8080). Si todo salió bien tenemos que estar viendo el Hello World! del index.jsp que el comando create de Maven2 generó con el archetype de webapp.

Pero queremos más... Queremos estar levantando un Servlet...

Paso 7 - Crear el HelloServlet:

Primero bajemos el Tomcat (stop tomcat), para que no ande molestando mientras tocamos el proyecto. Luego, en src/main creamos una carpeta llamada java donde vamos a poner nuestro código.

Lo siguiente que hacemos es poner esa carpeta en el build path. Para esto, botón derecho a la carpeta recién creada -> BuildPath -> Use as Source Folder. A continuación, creamos un paquete llamado servlets en src/main/java y creamos una clase HelloServlet que sobrecargue el método doGet para que imprima el Hello Servlet que nosotros queremos en la pantalla del browser:



package servlets;

import java.io.IOException;
import java.io.PrintWriter;


import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class HelloServlet extends HttpServlet {


  private static final long serialVersionUID = 1L;

  @Override
  protected void doGet(HttpServletRequest req, HttpServletResponse resp)

    throws ServletException, IOException {

    resp.setContentType("text/html");
    PrintWriter out = resp.getWriter();

    out.println("<h1>Hello Servlet!!!</h1>");
    out.close();
  }
}

Paso 8 - Agregar la dependencia de servlet-api en el Maven:

Por supuesto, una vez de copiar este códgio, veremos que el Eclipse no compila, ya que le falta las librerías de servlets en el classpath del proyecto.

En lugar de agregarlas en el proyecto de la forma tradicional, las agregaremos en el pom.xml (el archivo que Maven usa para compilar y que se encuentra en el root del proyecto). Dentro del tag de dependencies escribimos:


    <dependency>
       <groupid>javax.servlet</groupid>
       <artifactid>servlet-api</artifactid>
       <version>2.4</version>
       <scope>provided</scope>
   </dependency>

Acto seguido, para que Maven incluya en el proyecto de Eclipse la dependencia, haremos de vuelta en la consola un:

$ mvn eclipse:eclipse

Maven descargará el servlet-api-2.4.jar desde sus repositorios y lo agregará al proyecto. Si le damos F5 al proyecto en el Eclipse veremos que los errores de dependencias se han solucionado. El servlet-api-2.4.jar se ha agregado al classpath.

Paso 9 - Registrar el HelloServlet en el web.xml:

En el /src/main/webapp/WEB-INF/web.xml agregamos la referencia al servlet que acabamos de crear. Dentro del tag web-app, debajo de display-name agregamos:


   
  <servlet>   
           <servlet-name>HelloServlet</servlet-name>   
           <servlet-class>servlets.HelloServlet</servlet-class>
     </servlet>

   <servlet-mapping>   
           <servlet-name>HelloServlet</servlet-name>   
           <url-pattern>/HelloServlet</url-pattern>
    </servlet-mapping>

Paso 10 - Redireccionar la salida de los .class:

En /src/main/webapp/WEB-INF creamos la carpeta classes.

Luego, vamos a Propiedades del Proyecto y en Java Build Path seleccionamos la solapa Source. Aquí tenemos que tener HelloServlet/src/main/java y HelloServlet/src/main/resources. Seleccionamos Allow output folder for source folders y para ambas carpetas seleccionamos la ruta donde queremos que tire los .class compilados, que es la ruta donde el Tomcat buscará los servlets: HelloServletMaven/src/main/webapp/WEB-INF/classes. Se trata de la carpeta que acabamos de crear.

Paso 11 - Levantar el HelloServlet:

Levantamos de vuelta el Tomcat (start tomcat) y probamos en el browser si todo salió bien, a través de la dirección: http://localhost:8080/HelloServletMaven/HelloServlet. Si en la pantalla del browser vemos el Hello Servlet!!! quiere decir que todo salió bien.

Paso 12 - Buildear exitosamente con Maven:

Siguiente desafío: buildear exitosamente con Maven. Para esto usamos el comando:

$ mvn clean install

Si tenemos problemas para builder porque el Maven nos tira algo así:

/HelloServlet.java:[15,2] annotations are not supported in -source 1.3 (use -source 5 or higher to enable annotations) @Override
Significa que nuestro Maven, por default, está compilando con un JDK 1.3. Eso lo corregimos fácilmente agregando en el pom.xml del proyecto, dentro del tag build, debajo de finalName, lo siguiente:

    <plugins>
      <plugin>
         <groupid>org.apache.maven.plugins</groupid>
        <artifactid>maven-compiler-plugin</artifactid>
        <version>2.0.2</version>
         <configuration>
          <source>1.6</source>
          <target>1.6</target>
        </configuration>
      </plugin>
    </plugins>

De esta forma, le indicamos que queremos buildear este proyecto con el JDK 1.6, que por supuesto sí soporta annotations.

Podemos comprobar que en la carpeta target se generó el archivo HelloServletMaven.war. Les aseguro que este .war funciona perfecto. Si quieren hacer la prueba, despliéguenlo en el Tomcat y prueben con http://localhost:8080/HelloServletMaven/HelloServlet. Van a ver que el Servlet los saluda afectuosamente, como antes.

Introducción a EJB 3.0 - Parte 2

2008-09-11T19:35:00.000-07:00

En el post anterior de EJB3 presenté el libro de Manning Publications Co. EJB 3 In Action, de Bebu Panda, Reza Rahman y Derek Lane, edición de Abril de 2007 (ISBN: 1-933988-34-7). Más que nada, me centré en el primer capítulo del libro, que es gratuito y puede descargarse desde aquí. Expliqué qué es un EJB, cuáles son los distintos tipos de EJB que JavaEE provee, escribí un poco sobre los Entities y la JPA (Java Persistence API), expliqué qué es un contenedor de EJBs como Glassfish o JBoss, detallé cuáles son los servicios que proveen los EJBs, uno por uno, y por último presenté el HelloUser Example que se encuentra al final de este capítulo en el libro.

Para esta segunda parte, nos vamos a meter de lleno en esa maravilla que ofrece EJB 3 que es la Inyección de Dependencia y en una explicación concisa del ejemplo del capítulo 2 del libro, que se puede descarcar desde aquí.

Inyección de Dependencia

La Inyección de Dependencia (DI) es un concepto (o patrón) de arquitectura que está fuertemente emparentado con la Inversión de Control (IoC). Básicamente la DI se especializa en inyectar objetos en una clase, en lugar de ser la propia clase quien cree el objeto. En EJB 3 es el contenedor de EJBs quien inyecta en cada objeto los objetos necesarios según las relaciones plasmadas en los descriptores de despliegue o en las anotaciones.

Para el que le interese conocer más de este patrón, hay un artículo muy pero muy interesante de Martin Fowler que se llama: "Inversion of Control Containers and the Dependency Injection pattern". Fowler categoriza los distintos tipos de DI y ejemplifica cada uno con código de distintos frameworks. Cuando Fowler escribió este fascinante artículo, todavía no existía la especificación de EJB 3, por lo tanto no hay ninguna mención a esta forma de inyectar beans mediante anotaciones, pero igual vale la pena leerlo.

Uno de los grandes avances de EJB 3 es que nos permite reemplazar los descriptores XML de despliegue, en extremo verbosos y aburridos, por metadata annotations inmersas en el código (esto no se pudo lograr hasta que no salió la característica de annotations con Java5). En el ejemplo del post anterior, la inyección se llevó a cabo en el código del cliente. Mediante la anotación @EJB, se inyectó un objeto del tipo HelloUser en el atributo helloUser de la clase del cliente:

@EJB
private HelloUser helloUser;

Recordemos que HelloUser era una interface, por ende no se puede instanciar sin una implementación. El milagro en realidad sucedió cuando, en un código cualquiera de la clase del cliente, pudimos utilizar el objeto helloUser sin enfrentarnos a un NullPointerException, a pesar de no haber alocado memoria (new) en ninguna parte del código.

void hello() {
____helloUser.sayHello("Curious George");
}

El secreto está en la Inyección de Dependencia. La anotación @EJB, que parece tan inocente, es una orden directa al contenedor de EJBs para que cree una instancia de HelloUser con la implementación proporcionada del lado del servidor, que recordemos era ésta:

@Stateless
public class HelloUserBean implement HelloUser {
____public void sayHello(String name) {
________System.out.println("Hello " + name + " welcome to EJB 3!");
____}
}

¿Para qué sirve la DI entonces? En su forma más pura, la DI sirve para desacoplar completamente una interface de su implementación, por lo que podríamos cambiar de implementación en tiempo de ejecución. Noten que en ninguna parte del código del cliente es necesario utilizar la implementación HelloUserBean. Gracias al polimorfismo podemos usar su interface HelloUser sin tener conocimiento de HelloUserBean y, gracias a la DI, podemos olvidarnos del new HelloUserBean() que es lo único de lo que el polimorfismo no permite abstraernos.

En este caso, además, tenemos el adicional de que la DI reemplaza el terriblemente rutinario código de JNDI lookup, que los programadores de EJB 2 conocen mejor que yo. Una aplicación tradicional J2EE usa JNDI como mecanismo para que un componente pueda acceder a otro. El problema con JNDI es que acopla fuertemente el código del cliente con el código del servidor, con todas las desventajas que esto implica en el desarrollo y el testing.

Como ya dijimos, el objetivo principal de DI es hacer que los componentes estén lo menos acoplados posible. Cuando se usa JNDI, es responsabilidad del cliente buscar y obtener la referencia al objeto. La DI es exactamente lo opuesto a JNDI: es responsabilidad del contenedor inyectar un objeto basado en una dependencia declarada.

Ejemplo de la aplicación ActionBazaar

El ejemplo del capítulo 2 de "EJB 3 in Action" es muchísimo más completo e interesante. Trata sobre una aplicación llamada ActionBazaar, que no es más que un simple sitio de subastas como eBay.

En el ejemplo (recordemos que lo pueden bajar de la url del libro, en su versión para Glassfish, en su versión para oracleAS, o en su versión para JBoss; el código que nos ocupa es el de la carpeta: "chapter2"), se utilizan cuatro beans: dos Session Beans (PlaceBidBean y PlaceOrderBean) y un Message-Driven Bean (MDB) (OrderBillingMDB), que viven en la capa de lógica del negocio, y dos Entities, que viven en la capa de persistencia. Además, de los dos Session Beans, uno es un Stateless Bean (PlaceBidBean) y el otro es un Stateful Bean (PlaceOrderBean).

PlaceBinBean: un stateless bean

Los beans de sesión sirven para modelar procesos de negocio o acciones, especialmente los procesos y acciones percibidos por el usuario. Los stateless session beans, en particular, se usan para modelar acciones o procesos que pueden hacerse de una sola vez, que no necesitan guardar su estado.

En el gráfico de la sección anterior, vemos que PlaceBidBean es invocado desde la interfaz de usuario mediante el servicio addBid. Add Bid será un método del bean de sesión, que persistirá una oferta a través de Bid Entity.

@Local // Marks EJB business interface as local
public interface PlaceBid {
____public Bid addBid(Bid bid);
}

...

@Stateless // Marks POJO as stateless session bean
public class PlaceBidBean implements PlaceBid {
____...
____public PlaceBidBean() {}
____public Bid addBid(Bid bid) {
________return save(bid);
____}
}

PlaceBid puede ser llamado, por ejemplo, desde un JSP o un servlet. En el libro usan un servlet llamado PlaceBidServlet para invocar el servicio de addBid:

public class PlaceBidServlet extends HttpServlet {
____@EJB // Injects instance of PlaceBid EJB
____private PlaceBid placeBid;

____public void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

________// Se leen los datos que vienen en el request
________int bidderId = Integer.parseInt(request.getParameter("bidder_id"));
________int itemId = Integer.parseInt(request.getParameter("item_id"));
________double bidAmount = Double.parseDouble(request.getParameter("bid_amount"));

________// Se crea la oferta y se setean los atributos
________Bid bid = new Bid();
________bid.setBidderID(bidderID);
________bid.setItemID(itemID);
________bid.setBidAmount(bidAmount);

________// Se invoca el addBid del Bean de Sesión
________// Notar que jamás necesitamos
________// hacer un new de placeBid,
________// El contenedor ya lo hizo por nosotros.
________placeBid.addBid(bid);
________...
____}
}

PlaceOrderBean: un stateful bean

En el código anterior, cada llamada a addBid desde el servlet termina en la creación de una nueva oferta (Bid). En ningún momento el cliente se preocupa por el estado interno del bean, simplemente porque sabe que el estado de los atributos internos del bean nunca va a ser conservado (ni le interesa). El cliente ve como si cada llamada a un método del bean de sesión fuera ejecutado por una instancia distinta. Por eso, los Stateless Beans son utilizados para completar una acción en una única llamada.

Pero a veces necesitamos guardar ciertos datos, a veces necesitamos mantener una sesión. La aplicación de ActionBazaar usa un Stateful Session Bean para ejecutar el proceso de realizar el pedido, a través del bean PlaceOrderBean.

El proceso de realizar una orden o pedido es un proceso demasiado complejo para ejecutarlo en un solo paso. Hay todo un workflow involucrado que abarca desde agregar items a una orden hasta confirmar la misma orden, que se ve representado en el siguiente esquema:

Se necesita interacción con el usuario en cada uno de los pasos. Se necesita mantener abierta una sesión con datos temporarios que se conserven de una invocación a otra mientras dure el proceso. Con un Stateful Bean, los datos que el usuario ingresa en cada paso pueden mantenerse temporariamente en el bean hasta completar el workflow de pedido.

Cada uno de los pasos representados en el dibujo será implementado como un método de PlaceOrderBean, que serán invocados secuencialmente desde el cliente.

Definimos la interface remota PlaceOrder:

@Remote // Defines remote business interface
public interface PlaceOrder {
____void setBidderId(Long bidderId);
____void addItem(Long itemId);
____void setShippingInfo(ShippingInfo shippingInfo);
____void setBillingInfo(BillingInfo billingInfo);
____Long confirmOrder();
}

Luego, implementamos la interface y anotamos la implementación como un bean de sesión stateful:

@Stateful // Marks POJO as statefull
public class PlaceOrderBean implements PlaceOrder {

____// This four attributes
____// defines stateful instance variables
____private Long bidderID;
____private List items;
____private ShippingInfo shippingInfo;
____private BillingInfo billingInfo;

____public PlaceOrderBean () {
________items = new ArrayList();
____}
____public void setBidderID(Long bidderId) {
________this.bidderId = bidderId;
____}
____public void addItem(Long itemId) {
________items.add(itemId);
____}
____public void setShippingInfo(ShippingInfo shippingInfo) {
________this.shippingInfo = shippingInfo;
____}
____public void setBillingInfo(BillingInfo billingInfo) {
________this.billingInfo = billingInfo;
____}

____@Remove // Contains remove method
____public Long confirmOrder() {
________Order order = new Order();
________order.setBidderId(bidderId);
________order.setItems(items);
________order.setShippingInfo(shippingInfo);
________order.setBillingInfo(billingInfo);
________saveOrder(order);
________billOrder(order);
________return order.getOrderId();
____}
____...
}

Como estuvimos viendo hasta ahora, el bean no es más que un POJO con la anotación de @Stateful al comienzo. Es interesante notar que todos los atributos definidos al comienzo son los que el usuario irá seteando a lo largo de la sesión hasta llegar al último método, y el más importante, que es el que crea una orden, la persiste y la confirma.

La anotación @Remove marca el final del workflow modelado por el stateful bean. Es una forma de indicarle al contenedor de EJBs que tras ejecutar este método ya no necesita mantener la sesión del bean. Es un error muy grave no utilizar esta anotación en un stateful bean, ya que si nos la olvidamos, el contenedor quedará manteniendo el estado de las variables y la instancia del bean hasta que la sesión expire por medio de un timeout, lo que nos lleva a un desperdicio de preciosos recursos del servidor y una ralentización bastante seria de la aplicación.

El código del cliente no vale la pena incluirlo (recuerden que pueden ver el código completo descargándolo de la página del libro), ya que la DI se hace de la misma forma que ya estuvimos viendo y, salvo la invocación de los demás métodos que pertenecen al workflow, que no son más que simples invocaciones, no hay nada interesante en él. Lo verdaderamente interesante es que el código del cliente de un Stateful Bean y un Stateless Bean o de un bean local y un bean remoto es exactamente igual! Al cliente le da igual si el bean es remoto o si es local, ya que EJB 3 encapsula todo el manejo de RMI.

OrderBillingMDB: un message-driven bean

Así como un bean de sesión procesa request de negocio directos del cliente, los MDBs procesan mensajes indirectos. En los sistemas enterprise, la mensajería tiene numerosos usos, por ejemplo:

Integración de sistemas
Procesamiento asincrónico
Comunicación entre sistemas distribuidos

Para implementar una mensajería asincrónica, es necesario utilizar un intermediario entre el emisor del mensaje y el receptor. En JavaEE ese mediador se llama message-oriented middleware (MOM). Ejemplos comerciales de MOM en el mercado son: MQSeries de IBM o SonicMQ de Progress Software. EJB 3.0 estandariza esta capa intermedia de mensajería mediante el uso de los MDBs, que de alguna forma, sirven para encapsular el aburrido código de la API de Java Messaging Service (JMS).

El libro muestra la diferencia entre un código que usa directamente JMS y otro que usa un MDB, mediante un código que deja al descubierto la diferencia de cantidad, claridad y facilidad entre uno y otro (sale ganando el segundo, por supuesto). No es un tema que me interese tratar en este post. El tema de mensajería en JavaEE es tan complejo que, en todo caso, merece unos cuantos post separados. Al que le interese ver la implementación de un MDB, puede buscar en el código el bean OrderBillingMDB que implementa la interfaz MessageListener, para poder hacer uso de JMS a través del framework de EJB y además para poder implementar el método onMessage, que es donde se arma el mensaje propiamente dicho y se le adjuntan los objetos que se desean enviar. Además se usa la anotación @MessageDriven como anotador de la clase, que ya se imaginarán para qué sirve.

Persistiendo las Entidades Bid y Order a través de JPA

Gracias a Dios, en EJB 3, JPA no implementa el modelo de contenedores (como sí lo hacía en las versiones anteriores), sino que utiliza un paradigma de API, similar a JDBC, JavaMail o JMS. La interface EntityManager define la API de persistencia mientras que las entidades JPA especifican cómo se debe realizar el mapeo entre los datos de la aplicación y los registros de las tablas relacionales.

Veamos por ejemplo cómo sería la entidad Bid con las anotaciones correspondientes a JPA:

@Entity // Marks POJO as entity
@Table(name="BIDS") // Specifies table mapping
public class Bid implements Serializable {

____private Long bidID;
____private Long itemID;
____private Long bidderID;
____private Double bidAmount;
____private Date bidDate;

____@Id // Containes entity ID
____@GeneratedValue(strategy=GenerationType.AUTO)

____// Specifies column mappings
____@Column(name="BID_ID")
____public Long getBidID() {
________return bidID;
____}
____public void setBidID(Long bidID) {
________this.bidID = bidID;
____}

____@Column(name="ITEM_ID")
____public Long getItemID() {
________return itemID;
____}
____public void setItemID(Long itemID) {
________this.itemID = itemID;
____}

____@Column(name="BIDDER_ID")
____public Long getBidderID() {
________return bidderID;
____}
____public void setBidderID(Long bidderID) {
________this.bidderID = bidderID;
____}

____@Column(name="BID_AMOUNT")
____public Double getBidAmount() {
________return bidAmount;
____}
____public void setBidAmount(Double bidAmount) {
________this.bidAmount = bidAmount;
____}

____@Column(name="BID_DATE")
____public Date getBidDate() {
________return bidDate;
____}
____public void setBidDate(Date bidDate) {
________this.bidDate = bidDate;
____}
}

Es notable el poder de esta Entity. Es notable que Bid no es más que un POJO común y corriente, que no requiere ninguna interface, ni requiere heredar de ninguna clase rara. La anotación @Table sirve para mapear la clase a la tabla BIDS de la base de datos; @Column para mapear atributos a campos. El código es en verdad muy sencillo, y JPA no es para nada intrusivo.

Cuando mostré el código de los beans, al principio del ejemplo, obvié deliberadamente el método save. Recordemos que, por ejemplo, el addBid de PlaceBidBean invocaba a save para persistir la Bid recibida por parámetro. Veamos ahora esa parte de código:

@Stateless
public class PlaceBidBean implements PlaceBid {

____// Injects instance of EntityManager
____@PersistenceContext(unitName="actionBazaar")
____private EntityManager entityManager;

____...

____private Bid save(Bid bid) {
________// Persists entity instance
________entityManager.persist(bid);
________return bid;
____}
}

La persistencia se realiza a través del EntityManager que es inyectado por el contenedor de EJBs. El EntityManager puede ser visto como un "intérprete" entre el mundo de la orientación a objetos y el mundo de tablas relacionales. El EntityManager lee las anotaciones de la entidad que vimos unas líneas más arriba y, una vez que entiende cómo debe guardar el objeto en la base, cómo debe mapear el objeto en un registro de una tabla, lo hace. El EntityManager es inyectado en el bean PlaceBid a través de la anotación @PersistenceContext. Una unidad de persistencia es un grupo de entidades empaquetadas juntas en un módulo de aplicación. El atributo unitName de la anotación hace referencia a esa unidad de persistencia.

Cuando el EntityManager persiste una entidad, en realidad lo que está haciendo es generar SQL dinámico, SQL on the fly, el SQL que es capaz de leer el DBMS de la base de datos que fue configurada en el ORM. La llamada:

entityManager.persist(bid);

Podría generar un código SQL de este estilo:

INSERT INTO BIDS (BID_ID, BID_DATE, BIDDER_ID, BID_AMOUNT, ITEM_ID)
VALUES (52, NULL, 60, 20000.50, 100)

Dependiendo de los valores de los atributos del objeto enviado por parámetro.

Conclusión

EJB 3 es una especificación abierta de Sun Microsystem. Para utilizar EJBs necesitaremos un contenedor de EJB que implemente la especificación como Glassfish del mismo Sun o JBoss de Red Hat. El uso de EJBs en una aplicación enterprise nos abstrae de muchos crosscutting concerns como pueden ser integración, pooling, mensajería, transacciones, seguridad, dependencias, etc.

La especificación 3 de EJB presenta grandes ventajas frente a la 2, como el uso de anotaciones, en lugar de descriptores XML verbosos (que pueden seguir utilizándose y, de hecho, cuando no es posible volver a tocar un código, siguen siendo indispensables), un modelo de programación más liviano y menos intrusivo, una especificación de persistencia mucho más flexible (basada en los ORM que ya existían en el mercado) y el uso de inyección de dependencia en lugar del uso directo de JNDI lookup.

EJB 3 In Action es un muy buen libro, claro y completo, que es una referencia obligada para aquel que trabaje a diario con EJB 3.

Eclipse: User Libraries y Javadoc

2008-09-04T19:08:00.000-07:00

Cuando un proyecto de java crece se llena de apis libres que nos facilitan mucho las cosas, generalmente estas apis a su vez tienen como requerimientos otras jars, estos suelen ser comunmente las librerías de apache commons por poner un ejemplo.
Es común que al ejecutar nuestra aplicación comience a arrojar ClassNotFoundException cuando no encuentra estas apis, automáticamente empezamos a bajar jars para evitar estas excepciones.

Otro escenario son las apis que usamos frecuentemente y cuyo página en internet con la documentación consultamos asiduamente.

En ambos casos lo ideal sería utilizar las User Libraries de eclipse. Podemos crear librerías con los jars que usamos generalmente y asociarle su documentación, para de esta forma, al necesitar un jar, sólo agregamos la librería que creamos, y al necesitar consultar algo de documentación bastará con presionar control+barra espaciadora y mantener el mouse sobre una clase o método.

En este ejemplo vamos a crear una librería para Apache Commons Collections

1) Hacer click sobre el menu Windows, opción Preferences. Buscar Java/BuildPath/User Libraries. Hacemos click sobre NEW
2) Ingresamos un nombre descriptivo para la nueva librería

3) Seleccionamos la nueva librería y hacemos click sobre ADD JARS.... Buscamos los jars de la librería.

4) Para agregar la documentación seleccionamos javadoc location y hacemos click sobre edit

5) La documentación generalmente viene dentro del mismo zip donde se encuentran los jars. Puede ser que esta venga descomprimida o comprimida dentro de otro jar.
En caso de estar descomprimida tenemos que indicarle la carpeta donde de se encuentra el index.html de la documentación

O en caso de ser un jar, indicarle la ruta

Como se puede verse, se tienen las dos opciones disponibles, y de un botón Validate el cual nos mostrará el index de la documentación para verificar que se haya elegido la carpeta con la documentación apropiada.

6) Ahora sólo necesitamos agregar esta librería a un proyecto. Botón secundario sobre el proyecto Build Path/Add Libraries/User Libraries. En este caso agregamos Apache Commons Collections, que es el caso de nuestro ejemplo. Como se puede apreciar ya se puede disponer de esta api y de su documentación.

Reportes con iReport. Fuente de Datos : XML

2008-08-31T06:52:00.000-07:00

La clase JRXmlDataSource encapsula un archivo xml ya sea dinámico o estático para poder utilizarlo como fuente de datos en nuestro reporte.

Lo primero que debemos hacer es crear el template del reporte, esto lo haremos con iReport. Por ahora no será necesario escribir código.

Suponiendo que el XML será obtenido mediante un servicio u otro medio al ejecutarse la aplicación, necesitamos un XML de prueba, con la misma estructura del xml que le pasaremos al reporte. Por ejemplo este XML de prueba solo tiene dos personas, pero el que tengamos en la aplicación podrá tener 100, 15, lo que sea, sólo necesito la estructura, el nombre de las etiquetas.



<?xml version="1.0" encoding="UTF-8"?>
<personas>
     <persona>
         <nombre>Adrian</nombre>
         <edad>26</edad>
         <domicilio>Buenos Aires</domicilio>
    </persona>
    <persona>
         <nombre>Juan</nombre>
         <edad>15</edad>
         <domicilio>Chubut</domicilio>
   </persona>
</personas>

Abrimos iReport y creamos un nuevo reporte.

Vamos al menú Data y hacemos click sobre la opción Connections/Data Sources. En esta pestaña hacemos click sobre NEW y seleccionamos XML file data source y hacemos click sobre Next

En a nueva ventana podemos ponerle el nombre al DataSource y seleccionar el archivo de prueba con la estructura del XML.

Para comprobar si el datasource fue creado correctamente hacemos click sobre Test.
Para guardar el datasource hacemos click en save.

En este punto ya podemos definir el diseño del reporte. Hacemos click sobre Edit y buscamos la opción Report Query.
En el desplegable Query Language seleccionamos XPath. Automáticamente en la misma ventana se verá las etiquetas del xml de prueba.

Ahora necesitamos crear los campos que serán incluidos en el reporte. Por ejemplo nosotros vamos a querer hacer un listado de personas con nombre y domicilio, para ello agregamos en el campo de Query Language /personas/persona y arrastramos los nodos nombre y domicilio a la ventana inferior.

Aceptamos.

Si buscamos dentro de Document Structure / fields podemos encontrar los campos creados.

Arrastramos estos campos a la banda detail del reporte.

Finalmente guardamos el reporte.

Ahora podemos pasar a la parte de código. Haremos un sencillo programa que reciba por parámetro la ruta de un xml y que con este cree el reporte.



package test;

import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.util.HashMap;

import net.sf.jasperreports.engine.JRException;
import net.sf.jasperreports.engine.JasperCompileManager;
import net.sf.jasperreports.engine.JasperRunManager;
import net.sf.jasperreports.engine.data.JRXmlDataSource;

public class Test {

    public static void main(String[] args)
    {
         String filexml = args[0];
          try
          {
           System.out.println("Create DataSource...");
           File file =  new File(filexml);
           JRXmlDataSource xmlDataSource = new JRXmlDataSource(file,"/personas/persona");
           System.out.println("Compiling report...");
            
   
           JasperCompileManager.
           compileReportToFile("/home/paola/workspace/iReport/src/test/personas.jrxml");

            System.out.println("Filled report...");
            byte[] bytes = JasperRunManager.
                      runReportToPdf("/home/paola/workspace/iReport/src/test/Personas.jasper",new
                      HashMap(),xmlDataSource);

            String filePDF = filexml.substring(0,filexml.length()-3)+".pdf";
            FileOutputStream output = new FileOutputStream(filePDF);
                 
            output.write(bytes);
            output.flush();
            output.close();
             System.out.println("Done!");
          }
          catch (JRException e)
          {
            e.printStackTrace();
          } catch (FileNotFoundException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        } catch (IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }
}

Este es nuestro reporte final.

Aplicaciones:
iReport 3.0.0

Librerias utilizadas:
JasperReport 3.0.1

Requisitos de JasperReport:
JasperReport para funcionar necesita de una serie de apis, estas son:

BeanUtils (Download de http://commons.apache.org/)
Digester(Download de http://commons.apache.org/)
Collections(Download de http://commons.apache.org/)
Logging(Download de http://commons.apache.org/)
iText (Download de http://www.lowagie.com/iText/download.html)
Xalan (Download de http://apache.patan.com.ar/xml/xalan-j/)

Libros de JasperReport y de iReport:

JasperReports for Java Developers. Autor:David R. Heffelfinger
The Definitive Guide to iReport. Autor:Giulio Toffoli
The Definitive Guide to JasperReport. Autores:Teodor Danciu and Lucian Chirita

Introducción a EJB 3.0 - Parte 1

2008-08-27T10:32:00.000-07:00

Manning Publications Co. cuenta con una colección inmensa de libros dedicados a distintas tecnologías y/o herramientas de programación. En particular, en el mundo de Tecnologías Java, cuenta con unos 70 libros aproximadamente. Algunos de los ejemplos más populares son: POJOs In Action, dedicado al diseño y desarrollo de aplicaciones enterprise con frameworks livianos (Spring, EJB 3.0, etc), Spring In Action, dedicado exclusivamente al framework Spring, Hibernate In Action, cuya segunda edición pasó a llamarse Java Persistence with Hibernate, JBoss In Action, dedicado al contenedor y servidor de aplicacion de Red Hat, etc, etc, y un largo etc (incluso hay también un JUnit In Action).

En este post y en el siguiente, pretendo esbozar un vistazo furtivo de lo que podemos encontrar en el EJB 3 In Action, de Bebu Panda, Reza Rahman y Derek Lane, edición de Abril de 2007 (ISBN: 1-933988-34-7). El libro está compuesto por 5 grandes partes (decargar el índice):

Overview of the EJB landscape: una introducción bastante exhaustiva del mundo actual de los EJB con un ejemplo bastante completo y simple para ir introduciéndonos en la tecnología. (El primer capítulo es gratuito y se puede descargar desde aquí.)
Building Business Logic with EJB3: se encarga principalmente de la lógica de negocio, que es donde viven los EJB. Si bien los distintos tipos de EJB ya fueron presentados en los dos capítulos de la parte anterior, en esta sección se explican distintos aspectos de los mismos en mucho más detalle y profundidad. Tenemos un capítulo dedicado a los Session Beans, uno dedicado a la mensajería asincrónica con los Message-Driven Beans (MDBs), uno dedicado al funcionamientos interno de los contenedores y conceptos avanzados de EJB, y, por último, tenemos uno dedicado a las transacciones y el manejo de la seguridad en detalle.
Diving into the Java Persistence API (JPA): se encarga principalmente del estándar JPA surgido a partir de la especificación 3.0 de los EJB. Habla de cómo implementar un buen modelo de dominio con la utilización de simples POJOs, cómo construir y manipular la configuración de la metadata para el correcto funcionamiento de un ORM, cómo manipular las entidades persistentes mediante la interfaz de EntityManager provista por la especificación y un capítulo final dedicado al uso del Java Persistence Query Language (JPQL) para hacer consultas a la base de datos a través del ORM.
Putting EJB 3 into Action: provee una guideline para el uso efectivo de los EJB 3. El primer capítulo es gratuito (se puede descargar de aquí) y trata sobre cómo empaquetar los EJBs y las entidades, mediante los XML descriptors. El siguiente capítulo habla sobre los patrones de diseño de EJB 3 y JPA. Por último, el capítulo 13 habla sobre performance y escalabilidad en una aplicación enterprise que usa EJB 3 y las formas óptimas de configuración.
Migration and Interoperability Issues: esta última parte trata temas varios: cómo hacer una migración efectiva de una aplicación enterprise existente a EJB 3 (sobre todo desde EJB 2), cómo exponer EJBs como web services y discusiones sobre aplicaciones que usan JAX WS 2.0 y EJB 3 y, por último, da un pantallazo general de lo que es el esfuerzo de las comunidades open source de Sun y de Spring para unir y complementar estos dos frameworks que muchas veces se ven como enemigos, pero pueden resultar complementarios.
Apéndices: Al final cuenta con cinco apéndices que cubren los siguientes temas: un tutorial de JNDI y RMI, un vistazo furtivo a las bases de datos hoy existentes, referencias a las anotaciones de configuración y los descriptores XML existentes, e instrucciones para instalar y configurar el servidor de aplicaciones oficial de Sun, Glassfish, y cómo efectuar el despliegue de los códigos de ejemplo proporcionados a lo largo de todo el libro.

En este post y en el siguiente me enfocaré principalmente en la primera parte del libro, la que da una introducción al mundo de los EJB 3. Como mencioné antes, esta parte está dividida en dos capítulos. El primer capítulo es gratuito y se puede descargar gratis. El segundo capítulo no, pero trata sobre un ejemplo donde hay un vistazo general de lo que se va a ver a lo largo de todo el libro, y el ejemplo sí es gratuito (se pueden descargar los códigos fuentes para los servidores de aplicaciones de Glassfish, OracleAS y JBoss desde la página del libro).

¿Qué es un EJB?

Enterprise Java Beans (EJB) es una plataforma para construir aplicaciones de negocio portables, reusables y escalables usando el lenguaje de programación Java. Desde el punto de vista del desarrollador, un EJB es una porción de código que se ejecuta en un contenedor EJB, que no es más que un ambiente especializado (runtime) que povee determinados componentes de servicio.

Los EJBs pueden ser vistos como componentes, desde el punto de vista que encapsulan comportamiento y permite reutilizar porciones de código, pero también pueden ser vistos como un framework, ya que, desplegados en un contenedor, proveen servicios para el desarrollo de aplicaciones enterprise, servicios que son invisibles para el programador y no ensucian la lógica de negocio con funcionalidades trasversales al modelo de dominio (a menudo requerimientos no funcionales o aspectos). En la especificación 3.0, los EJB no son más que POJOs (clases planas comunes y corrientes de Java) con algunos poderes especiales implícitos, que se activan en runtime cuando son ejecutados en un contenedor de EJBs.

Los servicios que debe proveer el contenedor de EJBs deben ser especificados por el programador a través de metadata de configuración que puede escribirse como:

Anotaciones de Java5 intercaladas en el código de las clases.
Descriptores XML (archivos XML separados).

A partir de EJB 3 se puede usar cualquiera de estas dos técnicas. Las técnicas no son exclusivas, pueden coexistir anotaciones con descriptores XML y, en el caso de superponerse la metadata, los XML tendrán prioridad y podrán sobreescribir las anotaciones.

Algunos ejemplos de los contenedores más populares que hay actualmente en el mercado son: Glassfish, de Sun Microsystem, JBoss Application Server, de Red Hat, BEA Weblogic Server y Oracle Application Server, ambos de Oracle y WebSphere de IBM.

Una anotación transforma un simple POJO en un EJB.

Tipos de EJBs

Existen tres tipos de EJBs:

Session Beans: en una aplicación enterprise típica, dividida en cuatro grandes capas o layers (presentación, lógica de negocio (business logic), persistencia y base de datos (DBMS)), los Session Beans viven en la lógica de negocio. Hay dos grandes tipos de Session Beans: Stateless y Stateful, el primero no conserva el estado de ninguno de sus atributos de la invocación de un método a otro y el segundo conserva el estado a lo largo de toda una sesión. Los Session Beans Stateless son los únicos que pueden exponerse como web services.
Message-Driven Beans (MDBs): también viven en la lógica de negocio y los servicios que proveen son parecidos a los Session Beans, con la diferencia de que los MDBs son usados para invocar métodos de forma asincrónica. Cuando se produce la invocación de un método de un MDB desde un cliente, la llamada no bloquea el código del cliente y el mismo puede seguir con su ejecución, sin tener que esperar indefinidamente por la respuesta del servidor. Los MDBs encapsulan el popular servicio de mensajería de Java, JMS. Hay una analogía muy interesante en el libro que dice que los MDBs son a JMS lo que JDBC es a SQL.
Entities: los entities viven en la capa de persistencia y son los EJBs que manejan la Java Persistence API (JPA), también parte de la especificación de EJB 3.0. Los entities son POJOs con cierta metadata que permite a la capa de persistencia mapear los atributos de la clase a las tablas de la base de datos y sus relaciones.

Los Session Beans son invocados por el cliente con el propósito de ejecutar operaciones de negocio específicas, como por ejemplo podría ser chequear la historia crediticia del cliente de un banco. El nombre sesión implica que la instancia del bean estará disponible durante una unidad de trabajo (unit of work) y no sobrevivirá a una caída del servidor. Un bean de sesión sirve para modelar cualquier funcionalidad lógica de una aplicación.

Los MDBs también procesan lógica de negocio, pero un cliente nunca invoca a un método de un MDB directamente. El sistema de mensajería asincrónica propone la utilización de una capa intermedia en la comunicación entre el productor y el consumidor del mensaje. En EJB 3, esta capa se llama MOM (Message-oriented middleware). Básicamente la MOM es un software que permite funcionar como servidor de mensajería, reteniendo los mensajes del productor y enviándolos posteriormente al consumidor en el momento en que esté disponible para recibirlo. (Es un funcionamiento similar al de un servidor de correo electrónico.) Algunos ejemplos típicos de servidores de mensajería son WebSphere MQ de IBM, SonicMQ, Advanced Queueing de Oracle y TIBCO.

Entities y la Java Persistence API

Debido al auge de los frameworks ORM (Hibernate, TopLink, etc), Sun tuvo que replantear su complicada y anti-natural especificación de persistencia, que tanto dolores de cabeza le daba a los programadores que usaban EJB 2, al extremo que optó por reescribirla casi por completo. Así nació JPA.

JPA persiste automáticamente los objetos Java usando la técnica de ORM (mapeo objeto-relacional). Los ORM del mercado se han adaptado a esta especificación y, hoy en día, cualquier framework de persistencia ORM soporta JPA.

El estándar JPA define:

La configuración ORM mediante metadata que mapea entidades a tablas relacionales.
La interface EntityManager, que define una API estándar para realizar las operaciones de persistencia (CRUD) de las entidades.
El Java Persistence Query Language (JPQL), para consultas y lecturas de datos de aplicación persistidos (algo así como un SQL orientado a objetos).

En general, los contenedores proveen su ORM. Por ejemplo, JBoss provee Hibernate, Glassfish provee TopLink. JPA puede funcionar independientemente del resto de los componentes de EJB 3 y hasta puede ser usado en una aplicación desktop común y corriente, una aplicación Java SE.

Los entities son los objetos Java que se persisten en la base de datos. Mientras que los Session Beans son los verbos del sistema, las entidades son los sustantivos.

¿Qué es un contenedor de EJBs?

Así como cuando compilamos una clase simple de Java, necesitamos una Java Virtual Machine (JVM) para ejecutarla, necesitamos un contenedor de EJBs para ejecutar los Session Beans y los MDBs.

Un contenedor Java EE es un servidor de aplicaciones que es capaz de ejecutar EJBs, puede servir como web container y además puede incluir otras APIS y servicios, como por ejemplo el de persistencia. Algunos servidores de aplicaciones pueden proveer solamente un contenedor web, como es el caso de Apache Tomcat, o sólo proveer servicios de persistencia, como es el caso de Hibernate. Un servidor de aplicaciones como JBoss trae un servidor Apache Tomcat y un servidor Hibernate, que se ejecutan dentro de forma transparente.

¿Qué servicios proveen los EJBs?

Integración: Proveen una forma de acoplar en tiempo de ejecución diferentes componentes, mediante simple configuración de anotaciones o XMLs. El acoplamiento se puede hacer mediante Inyección de Dependencia (DI) o usando JNDI, como se hacía en EJB 2 (explicaré el concepto de Inyección de Dependencia en detalle en el próximo post). La integración es un servicio que proveen los beans de sesión y los MDBs.
Pooling: El contenedor de EJBs crea para componentes EJB un pool de instancias que es compartido por los diferentes clientes. Aunque cada cliente ve como si recibiera siempre instancias diferentes de los EJB, el contenedor está constantemente reusando objetos para optimizar memoria. El pooling es un servicio que se aplica a los Stateless Session Beans y a los MDBs.
Thread-safely: El programador puede escribir componentes del lado del servidor como si estuviera trabajando en una aplicación sencilla con un solo thread (hilo). El contenedor se encarga de que los EJBs tengan el soporte adecuado para una aplicación multi-usuario (como son en general las aplicaciones enterprise) de forma transparente, asegurando el acceso seguro, consistente y performante. Aplica a los beans de sesión y a los MDBs.
Administración de Estados: El contenedor de EJBs almacena y maneja el estado de un Stateful Session Bean de forma transparente, lo que significa que el programador puede mantener el estado de los miembros de una clase como si estuviera desarrollando una aplicación desktop ordinaria. El contenedor maneja los detalles de las sesiones.
Mensajería: Mediante los MDBs es posible desacoplar por completo dos componentes para que se comuniquen de forma asincrónica, sin reparar demasiado en los mecanismos de la JMS API que los MDBs encapsulan.
Transacciones: EJB soporta el manejo de transacciones declarativas que permiten agregar comportamiento transaccional a un componente simplemente usando anotaciones o XMLs de configuración. Esto significa que cuando un método de un EJB (Session Bean o MDB) se completa normalmente, el contenedor se encargará de commitear la transacción y efectivizar los cambios que se realizaron en los datos de forma permanente. Si algo fallara durante la ejecución del método (una excepción o cualquier otro problema), la transacción haría un rollback y es como si el método jamás se hubiera invocado.
Seguridad: EJB soporta integración con la Java Authentication and Authorization Service (JAAS) API, haciendo casi transparente el manejo transversal de la seguridad. Aplica a todos los Session Beans.
Interceptors: EJB introduce un framework liviano y simple para AOP (programación orientada a aspectos). No es tan robusto y completo como otros, pero es lo suficientemente útil para que sea utilizado por los demás servicios del contenedor para brindarnos de forma invisible los crosscutting concerns de seguridad, transacciones, thread-safely. Además, nosotros, como programadores, podemos agregar nuevos aspectos como logging o auditoria y demás de forma configurable.
Acceso Remoto: Es posible acceder de forma remota a distintos EJBs de forma sencilla, simplemente mediante la Inyección de Dependencia. El procedimiento para inyectar un componente local o uno remoto es exactamente el mismo, abstrayéndonos de las complicaciones especificas de RMI o similares. Este servicio aplica únicamente a los Session Beans.
Web Services: Un Stateless Session Bean puede publicar sus métodos como web services mediante una sencilla anotación.
Persistencia: EJB 3 provee la especificación JPA para el mapeo de objetos (Entities) a tablas.
Catching and Performance: JPA provee de forma transparente un importante número de servicios que permiten usar un caché de entidades en memoria y una lectura y escritura sobre la base de datos altamente performante.

HelloUser Example

Termino este post con el ejemplo provisto por el libro en este capítulo. El ejemplo cuenta con una simple interface llamada HelloUser con un único método sayHello. Luego, se muestra una clase que implementa esa interface, HelloUserBean, y que además, mediante una simple anotación, @Stateless, se le indica al contenedor que HelloUserBean es un Stateless Seasion Bean. A continuación, del lado del cliente, se muestra el código para inyectar el bean en un atributo privado llamado helloUser, del tipo HelloUser. En un método del cliente llamado hello(), se invoca el método sayHello() del bean de sesión (notar que sayHello() es un método que se ejecuta del lado del servidor, por ende la salida no se verá en la consola del cliente, sino en la consola del servidor, que a menudo es un archivo de log del servidor de aplicaciones).

Para inyectar de forma transparente el bean de sesión en el objeto del tipo HelloUser, se usa la anotación @EJB. Otra opción podría haber sido la única que había en EJB 2: localizar el componente mediante JNDI.

Código del Lado del Servidor

package ejb3inaction.example;
public interface HelloUser {
____public void sayHello(String name);
}

package ejb3inaction.example;
import javax.ejb.Stateless;

@Stateless
public class HelloUserBean implement HelloUser {
____public void sayHello(String name) {
________System.out.println("Hello " + name + " welcome to EJB 3!");
____}
}

Código del Lado del Cliente

...
@EJB
private HelloUser helloUser;

void hello() {
____helloUser.sayHello("Curious George");
}
...

El código de todo el libro, incluyendo este mismo ejemplo, que es el del capítulo 1, se puede descargar de la url del libro. En el próximo post me concentraré en la Inyección de Dependencia y en una explicación concisa del ejemplo del capítulo 2 del libro, que es bastante más interesante.