Tags: JEE

Tips: WELD-001400 Normal scoped bean is not proxyable

09 Feb 2011

Este error ocurre cuando por algún motivo Weld (la implementación para CDI) no es capaz modificar alguno de nuestros beans para inyectarle comportamiento.

En la práctica la solución a este problema es muy sencilla, es suficiente con revisar la clase (o la jerarquia de clases afectada) buscando algún método, atributo o clase interna marcada como final. Ya que si cualquiera de nuestros métodos está marcado como final la “mágia” CDI no podrá modificar nuestra clase.

Con esto el problema lo tendremos resuelto en la práctica, pero ahora nos queda una lavor mucho más difícil, convencer a  “los responsables de calidad” de lo absurdo que resulta que una de las reglas de validación de código sea “Design For Extension” que obliga a que todos los métodos no preparados para ser extendidos sean finales. Y es que estamos trabajando muy duro para mejorar nuestra calidad de código, pero nos estamos encontrando con que muchas reglas y pautas no encajan nada bien con el nuevo estándar JEE 6. Y que para conseguir que la arquitectura de una aplicación JEE 6 tenga una excelentes puntuaciones tenemos nos toca hacer un poco de código “espaqueti”.

Estrategias de generacion de identificadores con jpa

06 Feb 2011

Los identificadores para entidades JPA (@Id mapeados como Primary Keys) pueden ser identificadores naturales con algún tipo de significado para la aplicación (NIF, email, etc…) o generados por el sistema y automáticamente asignados al objeto (normalmente utilizando la anotación @GeneratedValue).
Hasta aquí nada nuevo, pero ahora vamos a repasar las diferentes estratégias disponibles:

Secuencia basada en TABLA
En esta estrategia hacemos uso de una tabla auxiliar con la que gestionar los identificadores secuenciales. En la tabla aparecerá una nueva fila por cada objeto de secuencia y cada ver que se necesite un nuevo identificador se incrementará la secuenca almacenada en la tabla y asignará dicho identificador.
Este mecanismo es uno de los más portables y es recomendable en casos de que deseemos maximizar la portabilidad de nuestra aplicación.


@Id
@GeneratedValue(strategy = GenerationType.TABLE)
public Long id;

En cuanto a rendimiento, esta solución ofrece un buen rendimiento ya que permite reservar grupos de identificadores de forma que se minimicen los accesos a dicha tabla y el comportamiento es muy bueno ya que permite conocer los identificadores sin necesidad de realizar el commit.
El único problema que plantea es que en determinadas ocasiones puede causar bloqueos. En concreto en las situaciones en las que el propio acceso a la tabla de secuencias se realice de forma transaccional y podamos tener otros procesos a su vez consumiendo dicha tabla. Por este motivo esta solución no es recomendable a no ser que se utilicen conexiones no-JTA para el acceso a la tabla de secuencias.

Identit

Esta estratégia de generación hace uso de un tipo de columna especial IDENTITY que está disponile en la mayoría de las bases de datos (desgraciadamente no está disponible en ORACLE).

Respecto a la portabilidad, este método de generación es portable ya a pesar de no estar disponible en Oracle puede ser facilmente simulado mediante trigers. Ofreciendo de una forma muy sencilla su potabilidad en el resto de bases de datos.
A pesar de ser un mecanismo muy utilizado, el principal problema de este mecanismo es su que no resulta nada eficiente, ya que dado que es la base de datos la que se encarga de autogenerar el valor, necesitaremos hacer un segundo acceso (en lectura) para conocer el identificador asignado. Al no poder realizar pre reserva de identificadores, este método es muy ineficiente y en general no recomendable.

Objeto de Secuencia
En este caso se hace uso de un tipo de recurso específico de las base de datos dedicado a la generación de secuenciaS. El principal problema que plantéa este método es que no está disponible en todas las bases de datos por lo que el código puede puede resultar no portable.
En cuento a rendimiento, ofrece una solución optima ya que permite definir bloques de identificadores reservados, de forma que se minimicen los accesos a la secuencia.


@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE)
public Long id;

Y aunque todos estos conceptos son relativamente conocidos por los que asiduamente utilizan JPA, hay que tenerlos muy encuesta si necesitas que su aplicación funcione sin problemas por ejemplo en SQL Server, PostgreSQL, Oracle y Mysql!

Plataforma de autenticación y firma digital sobre WebLogic

18 Jun 2010

La nueva versión de Viafirma, coincidiendo con su instalación en dos importantes entidades bancarias,  ofrece soporte oficial para Oracle WebLogic 11. De esta forma, junto con las plataformas ya soportadas por Viafirma (Tomcat 5, Tomcat 6, Websphere, etc…), ahora se incluye:

  • Oracle Fusion Middleware 11 / Weblogic 11g.
  • Oracle Enterprise Pack for Eclipse
  • Sun JVM 5, Sun JVM 6
  • SO: Linux,  Windows Server

El proceso de instalación es muy sencillo,  por lo que siguiendo los pasos del manual de instalación de Viafirma para Weblogic podremos disponer de sus servicios de autenticación (DNIe o cualquier otro certificado digital) y firma digital (XAdES, PAdES, CMS, CAdES, facturae, firma en lotes,…) desplegados sobre Weblogic .

WebSphere 6.1 y Viafirma

12 May 2010

Aunque ya contábamos con alguna instalación “custom” de Viafirma en Websphere,   con la nueva versión de Viafirma 2.6 y coincidiendo con su instalación en una importante entidad, pasamos a ofrecer soporte oficial tanto de la plataforma como de los kit de desarrollo en IBM Websphere 6.1.

Por lo que junto con las plataforma ya soportadas por Viafirma, ahora se incluyen:

  • WebSphere 6.0 y 6.1
  • IBM Websphere e IBM Rational Application Developer
  • JVM IBM 5.
  • SO: Linux, AIX, Windows Server

Viafirma en websphere

Por otro lado cabe destacar que el proceso de instalación es realmente sencillo, por lo que siguiendo los pasos del manual de instalación de Viafirma para Websphere podremos disponer de sus servicios de autenticación y firma digital (XAdES, PAdES, CMS, CAdES, facturae, firma en lotes,…)  en complejos entornos en cluster listos para producción en un tiempo record.

Creando una aplicación web basada en OSGI con Eclipse

29 Abr 2010

A continuación se describen los pasos básicos a dar para crear una aplicación web  que en lugar de ser desplegada sobre la típica pila JEE, sea desplegada como un componente más dentro de un contenedor OSGi.

Jee tradicional vs OSGi

Para ello se mostrará como construir con Eclipse un bundle OSGi que haciendo uso de Jetty nos permita correr un servlet sobre Equinox.

  • Crear el proyecto base

En primer lugar, necesitaremos crear un plugin, indicando que es de tipo OSGI (implementación Equinox).

Crear un proyecto OSGi en Eclipse

  • Definición de las dependencias

Una vez que tengamos el proyecto creado, necesitaremos declarar las dependencias que necesitará nuestro módulo para poder funcionar como un servidor de aplicaciones. Las dependencias serán como mínimo:

  • javax.servlet
  • org.eclipse.equinox.http.jetty
  • org.eclipse.equinox.http.servlet
  • org.mortbay.jetty.server
  • org.eclipse.equinox.http.registry

Dependencias Eclipse OSGI Jetty

  • Construcción del servlet de ejemplo

Una vez tengamos declaradas los módulos dependientes, Eclipse se encarga de actualizar nuestro classpath y ya podremos programar nuestro primer servlet sin problemas de compilación.

/** * Osgi Example Servlet. * */
public class HolaMundoOsgiServlet extends HttpServlet{
 protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        System.out.println("Petición al Servlet OSGi");
 	resp.getWriter().append("Respuesta desde un Servlet Osgi");
 }}

Como podemos ver, se trata de un servlet normal, que debería ser mapeado en el web.xml y desplegado dentro de un contenedor de servlets.

  • Activación del servlet

A diferencia del modelo tradicional (definido por la especificación JEE), la activación del servlet no requiere ningún web.xml. En su lugar, definiremos (al igual que cualquier otro servicio OSGI) un nuevo punto de extensión de nuestra aplicación. Para ello accederemos a la pestaña “Extension” y añadiremos la extensión “org.eclipse.equinox.http.registry.servlet” a nuestro módulo. Con esto le hemos indicado a OSGi que nuestro módulo hace uso del contenedor de Servlet.

Añadir extension point para definir un servicio de tipo servlet

El siguiente paso será indicar la clase que implementa el nuevo servlet y el mapeo, para ello simplemente definiremos la propiedad alias y class del nuevo servlet asociado a la extensión creada previamente.

Configurar extensiones OSGi

Con esto ya tenemos nuestra primera aplicación web OSGi.

  • Probando nuestra aplicación.

Para probar la aplicación sólo es necesario ejecutar el proyecto (Run As…>OSGi Framework) y acceder con el navegador a http://localhost:8080/exampleSi todo ha funcionado correctamente, en consola deberemos ver algo como lo siguiente:

Persistence bundle started.
Activado módulo OSGi: Ejemplo OSGI!!
Activado Servlet OSGiProviderTracker: New service detected...
ProviderTracker: Added service org.eclipse.persistence.jpa.osgi.PersistenceProviderOSGi
Petición al Servlet OSGi

Aunque aquí sólo se muestra un ejemplo muy básico, OSGI ya nos ha demostrado ser de mucha utilidad en proyectos reales muy complejos.

Java / JEE : Firma digital y autenticación con Viafirma (I)

29 Abr 2009

 

Este artículo pretende ser una guía rápida qué explique cómo realizar una operación de autenticación con Viafirma, de cara a obtener los datos del certificado digital del usuario. Aunque Viafirma ofrece todos sus servicios mediante métodos estándar (Servicios Web y OpenID), también disponemos  de un cliente para Java que permite de una forma muy sencilla integrar aplicaciones desarrolladas en esta tecnología con los servicios que ofrece Viafirma. En este artículo mostraremos cómo añadir las dependencias necesarias a un proyecto web Java para hacer uso de los diferentes servicios de firma digital (XAdES, Facturae, PDF sign, etc… ), autenticación (FNMT, Camerfirma, Firma profesional, Ancert, ACA, Izempe,  DNIe, etc…),  custodia (integridad, etc…)  y verificación (CRLS, OCSP, etc…). El procedimiento sería el siguiente: 1.- Añadir las dependencias

Viafirma está preparado para trabajar con Maven; en este tipo de proyectos sólo será necesario añadir la dependencia a viafirma-client de la siguiente manera:

<code>
<!--  Dependencias para el cliente viafirma con soporte de OpenID -->

 org.viafirma
 viafirma-client
 [2.2.3,2.3.0)

</code>

Y poner el repositorio de librerías de VIAVANSI para poder recuperar esta librería:

<code>http://repositorio.viavansi.com/repo</code>

Si el proyecto no está basado en Maven, necesitaremos añadir manualmente los .jar que se incluyen en el directorio dependency dentro del distribuible de viafirma-client. 2.- Crear la página de acceso a la autenticación A modo de ejemplo básico vamos a crear una jsp que inicialice el cliente de Viafirma y permite al usuario iniciar el proceso de autenticación pulsando en un enlace. Este cliente utilizará el servidor público de pruebas de Viafirma desplegado en las instalaciones de Viavansi.

<code><span style="color: #bf5f3f;">&lt;%@</span><span style="color: #3f7f7f;">page</span> <span style="color: #7f007f;">import</span><span style="color: #1a1a1a;">=</span><span style="color: #2a00ff;"><em>"org.viafirma.cliente.ViafirmaClientFactory"</em></span>%&gt;
<span style="color: #bf5f3f;">&lt;%@</span><span style="color: #3f7f7f;">page</span> <span style="color: #7f007f;">import</span><span style="color: #1a1a1a;">=</span><span style="color: #2a00ff;"><em>"org.viafirma.cliente.ViafirmaClient"</em></span><span style="color: #bf5f3f;">%&gt;</span>
<span style="color: #008080;">&lt;</span><span style="color: #3f7f7f;">body</span>&gt;<span style="color: #000000;">
&lt;%</span>
</code>

if

 (!ViafirmaClientFactory.isInit()) {

// Configuración básica del cliente. ViafirmaClientFactory.init(“http://viafirma.viavansi.com/viafirma”,“http://viafirma.viavansi.com/viafirma”

);
}

if(request.getParameter(“autenticar”)!= null){ ViafirmaClient viafirmaClient = ViafirmaClientFactory.getInstance(); // Iniciamos la autenticación indicando la uri de retorno. viafirmaClient.solicitarAutenticacion(request, response,“/viafirmaClientResponseServlet”); } %> <p><a href=“?autenticar=true”>Solicitar autenticacióna>p> body>

Cuando el usuario pulse sobre el enlace “Solicitar autenticación” el usuario será redirigido a Viafirma, donde se le solicitará su certificado digital. Viafirma validará y tratará el certificado del cliente y retornará el resultado de la autenticación a la aplicación cliente que estamos desarrollando. En la jsp de ejemplo le indicamos a Viafirma que la url de retorno (donde Viafirma debe mandarnos el resultado de la autenticación) es /viafirmaClientResponseServlet . 3.- Procesar la respuesta Una vez que Viafirma obtenga la información contenida en el certificado digital, retornará los datos a la url que la aplicación cliente le indicó, por lo que el siguiente paso será definir un servlet (cuya URL en este ejemplo es /viafirmaClientResponseServlet) que se encargue de gestionar la respuesta. Para ello crearemos un servlet que extiende de org.viafirma.client.ViafirmaClientServlet, e implementaremos los métodos error(…), cancel(…) y authenticateOK(…):

publicclassViafirmaClientResponseServletextendsViafirmaClientServlet{

@Override publicvoidauthenticateOK(UsuarioGenericoViafirmausuario,HttpServletRequestrequest,HttpServletResponseresponse){ // Lógicaespecíficadelaaplicaciónparagestionar el resultadodelaautenticaciónrequest.setAttribute(“usuarioAutenticado”,usuario); request.getRequestDispatcher(“/resultadoAutenticacion.jsp”).forward(request,response); }

@Override publicvoidcancel(HttpServletRequestrequest,HttpServletResponseresponse){ // Gestiónndecancelaciónndelusuarioalautenticar o firmar request.setAttribute(“error”,“El usuario ha cancelado la autenticación”); request.getRequestDispatcher(“/resultadoAutenticacion.jsp”).forward(request,response); }

@Override publicvoiderror(CodigoErrorcodError,HttpServletRequestrequest, HttpServletResponseresponse){ // Gestiónde error alautenticar o firmar request.setAttribute(“codError”,codError); request.getRequestDispatcher(“/resultadoAutenticacion.jsp”).forward(request,response); }

}

En este ejemplo vemos un ejemplo de implementación, en el que la aplicación simplemente guarda en request el objeto UsuarioGenericoViafirma que contiene todos los datos que aparecen en el certificado digital. Obviamente cada aplicación, en función de su lógica de negocio, deberá realizar la implementación específica que requiera. 4.- Adaptar la plataforma al skin de la aplicación cliente. La página donde se solicita el certificado digital reside en Viafirma. Sin embargo, a través de CSS podremos conseguir que el usuario no aprecie un cambio de interfaz, de forma que el salto de la aplicación a Viafirma parezca transparente a nivel estético. Para hacer que Viafirma se adapte fácilmente al estilo visual de nuestra aplicación cliente, sólo tendremos que colocar el fichero viafirmaStyle.css en el raíz de nuestra aplicación y redefinir el aspecto visual de la interfaz  de Viafirma. 5.- Descarga el cliente y pruébalo tu mismo Descargar ejemplo de autenticación utilizando el cliente Java para obtener los datos del certificado digital. Próximamente: Java / JEE : Firma digital XADES y facturae con Viafirma (II)

Sun’s RI for JSF vs MyFaces

21 Ene 2008

Época de despedidas, hoy le toca el turno a MyFaces

Después de más de dos años utilizando la implementación Apache Myfaces JSF, ha llegado el momento de las despedidas, en adelante todos nuestros proyectos se pasan a la implementación JSF 1.2 de Sun. No existe un motivo principal, pero si muchos pequeños problemas que finalmente nos han hecho decidirnos por la migración. Sin intención de entrar en detalle, estas son las motivaciones principales:

– En el momento de tomar la decisión, la implementación de Sun de la especificación 1.2 era mucho mas madura que la de Myfaces. En las pruebas realizadas pudimos comprobar que el numero de bugs es mucho mayor en la implementación Myfaces. En general Sun’s RI es una implementación mucho mas pulida.

– El número de incompatibilidades que hemos sufrido al migrar de la especificación 1.1 a 1.2 ha sido mucho menor con la implementación de Sun.

– Es posible seguir utilizando las librerías Tomahawk  con la implementación de Sun.

– La implementación de Sun parece ofrecer mejor rendimiento que la implementación de Myfaces.

– La integración con Seam es mucho mas sencilla utilizando la implementación de Sun.

– Gracias a la filosofía una especificación, múltiples implementaciones; el cambio era posible.

El falso Santo Grial de J2EE y la nueva esperanza JEE

01 Ene 2008

Con visión retrospectiva podemos ver que muchas de las bases sobre las que se sustentaba J2EE fueron un error.

En los primeros días de J2EE, los xmls eran vistos como el Santo Grial de la configuración, el framework estaba pensado para que todo se pudiera y tuviese que configurar en un xml, incluyendo nombres de clases java y métodos. Esta técnica que sobre el papel parecía ideal para ayudar al desacoplamiento del sistemas tenía consecuencias nefastas en el desarrollo.

La configuración en ficheros xml resultó ser muy repetitiva, propensa a errores (muy difíciles de encontrar en tiempo de ejecución) y en definitiva demasiado compleja para el programador medio.

Ahora, mirando hacia atrás podemos ver que no solo el propio J2EE, sino también otros frameworks como Hibernate, Struts, Spring, iBatis, etc… cometieron el mismo error, y poco a poco la plataforma Java se ha ido haciendo cada vez más y más compleja, hasta ser considerada por algunos como un dinosaurio inmanejable, con una dura curva de aprendizaje.

Esta situación, conocida como “El infierno XML“, la han aprovechado muy bien otros lenguajes como Ruby on Rails con su lema programación por convención, que precisamente evita la trampa en la que cayó J2EE.

Por suerte la comunidad Java ha reconocido el problema del abuso de XMLs y ha actuado remplazando parcialmente los ficheros XML con una mezcla de anotaciones en el código y convenciones establecidas que sólo requieren la configuración de los casos excepcionales.

Como respuesta a estos y otros problemas, han empezado a aparecer algunas soluciones como por ejemplo:

* EJB3/JPA: Que simplifica dramáticamente el engorro que actualmente suponía trabajar con EJBs 2.0 o Hibernate y que desde hace un año forma parte de todas nuestras aplicaciones con unos resultados excelentes.

* Seam: Un framework ligero para Java EE 5.0 que simplifica el desarrollo de aplicaciones web y que despues de algunos proyectos internos, se convierte este año 2008 en nuestro framework base para todos nuestros nuevos proyectos web.

* Web Beans (JSR 299): La gran esperanza que parte del camino iniciado por Seam y que pretende convertirse, al igual que ya pasó con JPA, en el estándar para comunicar la capa web con los EJBs.

* Grails: Que ha resultado muy ilusionate en las pruebas y quizás en el futuro se convierta tambien en compañero de viaje.

* JAX-WS 2.x: Que simplifica enormemente tanto la publicación como el consumo de Servicios Web. Después de años utilizando Axis, JAX-WS pasa a convertirse en nuestra pila Web services preferida.

En definitiva, aunque los XMLs seguiran siendo parte esencial de nuestro día a día, un nuevo camino se abre en los paradigmas de programación Java, …