Xnoccio

Que pasaría si al hacer una entrega de software al cliente le decimos:

“Estoy seguro de que nos olvidamos de algo, y sé que tenemos algunos conflictos pendientes. Al mismo tiempo, necesitamos la cobertura de una versión real, y en su conjunto tiene muy buen aspecto. Hemos corregido unos cuantos conflictos en los últimos días, y siempre tendremos las versiones 2.6.30.x (parches).“

Pues este es precisamente el mensaje con el Linus Torvalds dio a conocer la versión 2.6.30 del Kernel de Linux!! (el mensaje original en: http://lkml.org/lkml/2009/6/9/710). Sería impensable que le dijéramos una frase similar a un cliente.

Salvando los posibles problemas con clientes que “entren en pánico” debido a este derroche de sinceridad, y ahora que está tan de moda las políticas de calidad, objetivos, métricas, … Nuestro objetivo es que la calidad de nuestras aplicaciones esté tan demostrada, que en una situación puntual le podamos decir a un cliente una frase tan sincera como ésta, sin que el cliente sienta ningún tipo de angustia.

Un ejemplo de reutilización de código e ingeniería de “software” en Disney. Tengo la sensación de que no pasaría los test de duplicación de código…

Visto en Con Código

Recientemente se ha liberado la primera versión estable de Weld, la implementación de referencia de Web Beans (Java Context and Dependenty Injection - JSR 299). Y aunque puede parecer una liberación cualquiera, en este caso estamos ante un evento realmente importante para el mundillo Java.

¿Por qué es importante esta liberación?

• Por fin tenemos un estándar Java para la inyección, publicación, localización y búsqueda de componentes.
• Promete una mejor orquestación entre componentes JEE, evitando los típicos problemas de interoperabilidad entre Beans Spring, componentes Seam, Wicket, JSF, EL, etc..)
• Un remplazo estándar a las diferentes soluciones de inyección e IoC como Spring IoC, el prometedor Google Guice o el muy utilizado por nosotros Jboss Seam annotations.
• Fin del infierno XML, definiendo un mecanismo estándar independiente de ficheros de definición XML, que junto con JSF 2.0, Servlet 3.0, JPA, Jax-ws, etc… simplifican el desarrollo JEE.

¿Consecuencias para la industria a medio plazo?

• Es demasiado pronto para saberlo, pero…
  ¿Quizás el fin de la guerra de frameworks se inyección?…. (Google Guice vs Spring vs Jboss Seam). Consiguiendo un efecto similar al que consiguió JPA/JDO estandarizando el acceso a datos.
• Por fin una especificación JEE con la que construir aplicaciones complejas de forma sencilla.
• En un momento en el que muchas organizaciones están intentando estandarizar sus desarrollos, llegando incluso a restringir o imponer las tecnologías utilizadas, la preselección de implementaciones como Spring IoC o Seam carecerá de sentido. Siendo mucho más coherente la recomendación de estándares en lugar de restringir la evolución natural de la tecnología y la sana competición entre sus diferentes implementaciones.

¿Consecuencia para nosotros?

• Ninguna…. Gracias a nuestra apuesta por Jboss Seam (desde hace ya unos años), esta especificación se encontraba ya en nuestra hoja de ruta antes incluso de que fuese un Draft, por lo que para nosotros será suficiente con una mínima adaptación al estándar.
• La implementación es estable, la especificación muy bien pensada, y en las pruebas que hemos realizado con la beta, ha demostrado que consigue simplificar los desarrollos y hacer más comprensible el “oscuro arte de la inyección de componentes”.
• En breve empezaremos a usarla en algún proyecto piloto (que pueda asumir el riesgo de I+D asociado), analizaremos en detalle los posibles problemas que puedan surgir, y si todo se comporta como promete a mediados de 2010 empezaremos a usar la nueva especificación en nuestros proyectos Java.

¿Defectos?

• Llega demasiado tarde. Otros frameworks llevan, aunque de una forma mucho menos limpia,  ofreciendo algo similar desde hace ya mucho tiempo.
• Todavía no conocemos sus defectos. Y eso es un gran problema ya que hasta que no conozcamos sus problemáticas asociadas no será seguro su uso en proyectos de envergadura.
• Esperemos que en la huida del infierno de los ficheros de configuración XML, no nos metamos en  las tinieblas del uso de inyección e IoC para todo. Ya que una aplicación con una gran cantidad de componentes, comportamientos o atributos que dependen de la inyección hace muy complicada la comprensión de su funcionamiento.

En definitiva, todo indica que estamos antes una de las piezas clave del próximo JEE 6.

Objetivos

El objetivo de este artículo es servir de guía básica para la migración manual de proyectos Java no Maven a entorno Maven. Pensado y dirigido especialmente a personas con poca  experiencia previa en Maven, pero con algún conocimiento previo.

Preparación del proyecto

Como es obvio, para migrar un proyecto Java a Maven, deberemos disponer de sus fuentes y todas las librerías dependientes.

Ya que vamos a realizar modificación estructurales importantes en el proyecto, conviene asegurarnos de que los fuentes no están conectados a ningún sistema de control de versiones como Subversion. Para realizar esto, podemos o bien eliminar manualmente todos los directorios .svn de nuestro proyecto o bien desde Eclipse desconectar el proyecto.

Si lo vamos a realizar de forma manual, debemos asegurarnos de eliminar todos los directorios .svn (o .CVS si el proyecto a migrar estuviese conectado a un CVS) A modo de ejemplo, en Linux podemos ejecutar el siguiente comando desde el directorio del proyecto para eliminar todas las referencias a carpetas ‘.svn’:

rm -rf `find . -type d -name .svn`

Será mucho más sencillo hacerlo de forma automática desde Eclipse. Para desconectar el proyecto, teniéndolo seleccionado pulsaremos sobre el botón derecho del ratón: Team -> Disconnect.

Adaptación del proyecto

Aunque la estructura por defecto Maven puede ser modificada, es muy recomendable adaptar la organización del proyecto a migrar a la estructura por defecto más generalizada:

Para hacer esta modificación de la estructura hay que tener especial cuidado en algunos aspecto o convenciones Maven:

• Los ficheros de recursos: Maven hace una distinción entre los ficheros de clases java y los ficheros de recursos .properties y XML’s y, de hecho, salvo que le digamos lo contrario, no hará ningún tratamiento de los ficheros no java que se encuentren en el directorio src/main/java. Por este motivo, tendremos que localizar todos los ficheros de recursos (properties, XML’s) que se encuentran en el directorio java y moverlos al directorio resources (src/main/resources).
• Eliminar la carpeta classes. Es muy común que proyectos no Maven tengan en su carpeta WEB-INF/classes los compilados del proyecto. Esta situación no sólo no es recomendable sino que puede producir problemas, por lo que los eliminaremos confiando en Maven para su generación cuando sea necesario.

Definir el pom.xml del proyecto

Una vez que la estructura del proyecto se ha adaptado a la filosofía Maven, el siguiente paso es definir el pom.xml del proyecto.

Partiremos de un fichero pom.xml básico. Este fichero de origen no tiene dependencias; durante el proceso lo adaptaremos y posteriormente iremos refinando la configuración hasta alcanzar una “mavenización” completa del proyecto.

Una vez colocado el pom.xml en el raíz de la aplicación, lo modificamos indicando el nombre del proyecto y la información básica relativa a los desarrolladores, organización y repositorio de dependencias utilizado.

Antes de continuar y añadir las dependencias, podemos hacer una comprobación previa y verificar que efectivamente nuestro IDE, en este caso Eclipse, reconoce correctamente la nueva estructura del proyecto.

Para ello nos vamos a la consola y en el directorio en el que se encuentra nuestro proyecto ejecutamos la siguiente orden:

mvn clean eclipse:eclipse

(Requiere disponer de Maven correctamente instalado en la máquina).

Si la configuración del entorno es correcta, obtendremos una salida similar a esta:

[INFO] Scanning for projects…
[INFO] Searching repository for plugin with prefix: ‘eclipse’.
[INFO] ————————————————————————
[INFO] Building ejemplo
[INFO]    task-segment: [clean, eclipse:eclipse]
[INFO] ————————————————————————
[INFO] [clean:clean]
[INFO] Deleting file set: /home/felix/workspaces/ejemplo/target (included: [**], excluded: [])
[INFO] Preparing eclipse:eclipse
[INFO] No goals needed for project - skipping
[INFO] [eclipse:eclipse]
[INFO] Adding support for WTP version 1.5.
[INFO] Using source status cache: /home/felix/workspaces/ejemplo/target/mvn-eclipse-cache.properties
[INFO] File /home/felix/workspaces/ejemplo/.project already exists.
       Additional settings will be preserved, run mvn eclipse:clean if you want old settings to be removed.
[INFO] Wrote Eclipse project for “ejemplo“ to /home/felix/workspaces/ejemplo.
[INFO]
       Sources for some artifacts are not available.
       Please run the same goal with the -DdownloadSources=true parameter in order to check remote repositories for sources.
       List of artifacts without a source archive:
         o javax.servlet:servlet-api:2.4
         o javax.servlet.jsp:jsp-api:2.1
         o junit:junit:3.8.1 

[INFO] ————————————————————————
[INFO] BUILD SUCCESSFUL
[INFO] ————————————————————————
[INFO] Total time: 4 seconds
[INFO] Finished at: Wed Sep 3 11:54:28 CET 2008
[INFO] Final Memory: 10M/80M
[INFO] ————————————————————————

Nos vamos a Eclipse, refrescamos el proyecto (F5 teniendo seleccionado el proyecto) y comprobamos que la nueva estructura es correcta.

Ahora que hemos comprobado que eclipse ha reconocido la nueva estructura, el siguiente paso es definir en nuestro pom.xml las dependencias. Para hacer esto eliminamos todos los .jar que se encuentran en el directorio /WEB-INF/lib y nos quedamos con una copia de ellos para posteriormente ir resolviendo las dependencias del proyecto original. Una recomendación es cortar la carpeta /WEB-INF/lib a otra ruta de nuestro disco.

Resolución de dependencias

Esta es la fase más delicada del proceso, ya que debemos asegurarnos de que todas las dependencias del proyecto quedan correctamente declaradas en el fichero pom.xml. Para realizar esta tarea es recomendadle utilizar alguna aplicación web que nos ayude a la localización de las librerías, como por ejemplo MvnRepository o MvnBrowser (recomendada), en la que podremos buscar cada uno de nuestros jar y encontrar la definición en el pom.xml que debemos utilizar.

Gracias a esta web, una vez que tengamos localizada la dependencia, solo tendremos que copiar el bloque POM Dependency a nuestro fichero pom.xml.

Iremos repitiendo este proceso de forma iterativa para todos nuestras librerías .jar y añadiendo la definición de la dependencia a nuestra zona de dependencies, con ciertas salvedades y consideraciones que introducimos a continuación.

Consideraciones especiales

Hay ocasiones en las que determinar la definición de la dependencia en nuestro pom.xml puede no ser una tarea trivial. Se comentan a continuación los mecanismos de actuación recomendados según diversas casuísticas:

• No se indica la versión de la librería en el nombre del fichero.

Por ejemplo, podemos encontrarnos una librería llamada axis-ant.jar, por lo que tendremos que averiguar previamente la versión de la librería de cara a definir la dependencia en el fichero pom.xml. Para esto suele ser muy efectivo descomprimir la librería y consultar el fichero /META-INF/MANIFEST.MF. A modo de ejemplo, en dicha librería mencionada observaríamos una linea similar a la siguiente: “Implementation-Version: 1.2.1 2243 June 14 2005″. Una vez que conozcamos la versión podremos realizar la búsqueda de la forma usual. , 1.1.1.1. Sabemos que la librería fue generada por maven, pero no conocemos su definición.

No conocemos el groupId, artifactId, etc. Podemos descomprimir el .jar y acceder al fichero pom.xml que se encuentra en /META-INF/maven para comprobar el groupId, artifactId y versión de la dependencia.

• Dependencias especiales JEE.

Algunos jars, como por ejemplo servlet.jar, son aportados por el contenedor de aplicaciones, por lo que tendremos que definirlas marcándolas como provided. Esto le indica a Maven que estas librerías pueden ser utilizadas en tiempo de compilación, pero no serán agregadas al empaquetado final. Para declarar una dependencia de esta forma incorporaremos en nuestro pom.xml un código como este:

<dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>servlet-api</artifactId>
      <version>2.4</version>
      <scope>provided</scope>
</dependency>

• Librerías ya consideradas en las dependencias transitivas

Muchas de las dependencias dependen a su vez de otras librerías, por lo que Maven añadirá de forma transitiva nuevas librerías a nuestro proyecto. En estos casos no necesitamos definir estas nuevas dependencias transitivas en nuestro pom.xml. Como ejemplo, supongamos que un proyecto depende de estas librerías:

• xalan-2-6.0.jar
• xercesImpl
• xml-apis

Al buscar la librería xalan-2-6.0.jar, observamos que la librería depende a su vez de las otras dos librerías. Por ello, para este ejemplo bastaría con declarar la dependencia a xalan-2-6.0.jar en nuestro pom.xml. 

• Conflictos entre librerías

En ocasiones nos podemos encontrar con que dos librerías tengan en sus dependencias a una misma tercera librería, pero de distinta versión. Ello haría que maven incluyese en nuestro Classpath 2 versiones de una misma librería, originando conflictos por duplicado de clases. En ese caso debe declararse en la dependencia de una de ellas una directiva para excluir la descarga de la librería conflictiva.

Por ejemplo, en un proyecto deseamos utilizar la librería siguiente:

<artifactId>jaxws-api</artifactId>
<groupId>javax.xml.ws</groupId>
<version>2.1-1</version>

Y tenemos dependencia a com.sun.xml.ws / jaxws-rt, esta librería se trae como dependencia transitiva otra versión de la librería mencionada anteriormente. Declaramos una exclusión para evitarlo:

<dependency>
  <groupId>com.sun.xml.ws</groupId>
  <artifactId>jaxws-rt</artifactId>
  <version>2.1.4</version>
  <exclusions>
    <exclusion>
      <artifactId>jaxws-api</artifactId>
      <groupId>javax.xml.ws</groupId>
    </exclusion>
  </exclusions>
</dependency>

• Tenemos una librería que se encuentra en los repositorios, pero no hemos podido averiguar el número de versión.

En esta situación, si la librería no parece problemática, podríamos optar por elegir la última versión de la dependencia. En el caso de que consideremos que la versión que utiliza el proyecto puede originar problemas, lo mejor es añadir esta librería manualmente a nuestro repositorio (como si fuese una librería específica del proyecto), según se explica en el próximo punto.

• La librería es específica del proyecto.

En estos casos tendremos que subir la dependencia a nuestro repositorio de librerías y, para evitar conflictos posteriores, se recomienda que sea subida con el mismo groupId de nuestro proyecto. Supongamos que migrando un proyecto nos topamos con librería example1.jar que no se encuentra en ningún repositorio público. En este caso la subimos a nuestro repositorio por ejemplo con la siguiente definición:

<dependency>
    <groupId>com.viavansi.examples</groupId>
    <artifactId>example1</artifactId>
    <version>0.0.1</version>
</dependency>

En la siguiente figura vemos cómo desplegamos una librería a Artifactory:

Comprobación de dependencias

Una vez que hayamos finalizado este proceso de definición de todas las dependencias en nuestro pom.xml, ejecutaremos en consola mvn dependency:tree (situados en el directorio donde se encuentre el fichero pom.xml del proyecto) para comprobar que las dependencias que se han incorporado al proyecto son las correctas. Este paso de verificación es muy importante en las migraciones de este tipo de proyectos, ya que es muy posible que alguna dependencia transitiva genere problemas. Como ejemplo, podemos observar la siguiente salida en la que comprobamos que no hay dependencias transitivas que entren en conflicto con alguna de nuestras librerías:

[INFO] [dependency:tree]
[INFO] com.viavansi.examples.examples1:war:0.0.1
[INFO] +- junit:junit:jar:3.8.1:test
[INFO] +- javax.servlet.jsp:jsp-api:jar:2.1:provided
[INFO] +- javax.servlet:servlet-api:jar:2.4:provided (scope not updated to compile)
[INFO] +- javax.activation:activation:jar:1.1:compile
[INFO] +- avalon-framework:avalon-framework-impl:jar:4.1.5:compile
[INFO] +- axis:axis-ant:jar:1.2.1:compile
[INFO] +- axis:axis:jar:1.2.1:compile
[INFO] +- javax.mail:mail:jar:1.3.1:compile
[INFO] +- commons-beanutils:commons-beanutils:jar:1.6:compile
[INFO] +- commons-codec:commons-codec:jar:1.3:compile
[INFO] +- commons-collections:commons-collections:jar:3.2:compile
[INFO] +- commons-dbcp:commons-dbcp:jar:1.2.2:compile
[INFO] +- commons-digester:commons-digester:jar:1.6:compile
[INFO] |  - xml-apis:xml-apis:jar:1.0.b2:compile
[INFO] +- commons-discovery:commons-discovery:jar:0.2:compile
[INFO] +- commons-httpclient:commons-httpclient:jar:3.1:compile
[INFO] +- commons-io:commons-io:jar:1.3.1:compile
[INFO] +- commons-lang:commons-lang:jar:2.2:compile
[INFO] +- commons-logging:commons-logging:jar:1.1:compile
[INFO] |  +- logkit:logkit:jar:1.0.1:compile
[INFO] |  - avalon-framework:avalon-framework:jar:4.1.3:compile
[INFO] +- commons-pool:commons-pool:jar:1.3:compile
[INFO] +- displaytag:displaytag:jar:1.1:compile
[INFO] +- displaytag:displaytag-export-poi:jar:1.1:compile
[INFO] +- dom4j:dom4j:jar:1.6.1:compile
[INFO] +- org.extremecomponents:extremecomponents:jar:1.0.1:compile
[INFO] +- com.lowagie:itext:jar:1.4.8:compile
[INFO] +- oro:oro:jar:2.0.7:compile
[INFO] +- javax.xml:jaxrpc-api:jar:1.1:compile
[INFO] +- javax.servlet:jstl:jar:1.1.2:compile
[INFO] +- log4j:log4j:jar:1.2.8:compile
[INFO] +- com.oracle:ojdbc14:jar:9.0.2.0.0:compile
[INFO] +- poi:poi:jar:2.5.1-final-20040804:compile
[INFO] +- javax.xml.soap:saaj-api:jar:1.2:compile
[INFO] +- org.springframework:spring:jar:2.0.5:compile
[INFO] +- taglibs:standard:jar:1.1.2:compile
[INFO] +- struts:struts:jar:1.2.9:compile
[INFO] |  +- commons-fileupload:commons-fileupload:jar:1.0:compile
[INFO] |  +- commons-validator:commons-validator:jar:1.1.4:compile
[INFO] |  - antlr:antlr:jar:2.7.2:compile
[INFO] +- wsdl4j:wsdl4j:jar:1.5.1:compile
[INFO] +- wss4j:wss4j:jar:1.5.0:compile
[INFO] +- xalan:xalan:jar:2.6.0:compile
[INFO] +- org.apache.xmlgraphics:xmlgraphics-commons:jar:1.2:compile
[INFO] +- xml-security:xmlsec:jar:1.2.1:compile
[INFO] +- org.directwebremoting:dwr:jar:2.0.3:compile
[INFO] +- com.viavansi:plantilla-client:jar:0.0.13:compile
[INFO] +- net.sourceforge.barbecue:barbecue:jar:1.5-beta1:compile

En caso de detectar librerías duplicadas a causa de las dependencias transitivas, deberemos proceder a definir las exclusiones necesarias en las dependencias afectadas, según se indicó anteriormente.

Por compatibilidad y por deseo de la mayoría de nuestros clientes, prácticamente todos nuestros proyectos Java han sido desarrollados con la versión Java SE 5 en mente. Pero esperamos que esta situación cambie este Otoño, ya que el soporte estándar para Java 5 termina el 30 de Octubre de 2009.
Después de esta fecha la versión 5 podremos considerarla deprectad, y aunque será posible contratar servicios de soporte Business a Sun, lo razonable será que el grueso de nuestros clientes por fin realicen la migración a Java 6 (que por cierto ya tiene unos añitos).

El único punto débil para realizar por fin esta deseada migración la tendremos con los clientes que quedarán anclados a la versión 5, de forma voluntaria u obligatoria, como por ejemplo los que usan la implementación Java de IBM para AIX ya que en este caso ni siquiera existe la JVM para Java 6.

Más información en http://java.sun.com/products/archive/eol.policy.html

Nuestro compañero Juan G. Hurtado (experto en css, web semántica, …) ha iniciado un nuevo blog y su intención es empezar desde un XHTML sin estructura ni diseño e ir mostrandonos en “directo” el nacimiento de un blog.

Iteración 0:
http://coloresefimeros.com/2009/07/19/iteracion-00-comenzando/

Iteración 1:
http://coloresefimeros.com/2009/07/22/iteracion-01-el-theme-y-el-xhtml/

Iteración 2:
http://coloresefimeros.com/2009/07/29/iteracion-02-primeros-pasos-con-css/

(El resto de iteraciones en)…
http://coloresefimeros.com/category/iteraciones/

Para los que no le conozcan, nuestro compañero es el de la izquierda:

Al igual que ocurre a la hora de utilizar lectores de tarjetas criptográficas en Linux normalmente  la existencia de drivers es uno de los grandes problemas, ya que en ocasiones los fabricantes sólo se preocupan por la versión Windows. Afortunadamente esta situación ha cambiado y actualmente es muchísimo más fácil hacer uso de estos lectores en Mac OS X. A continuación, y extraído de las prueba de compatibilidad que en su día realizamos para comprobar el comportamiento de Viafirma con estos lectores, vamos a hacer un pequeño repaso por fabricante sobre cómo instalarlos.

Instalación del driver para lectores que comercializa C3PO.  (Si tu lector no es de C3PO puedes saltar este apartado)Actualmente C3PO comercializa varios tipos de lectores compatibles con libccid (driver ya incluido en MacOS), por lo que podremos utilizarlos en MacOS directamente. Aunque actualmente comercializa varios tipos de lectores, durante las pruebas hemos podido comprobar el correcto funcionamiento del lector LCT31 y del teclado con lector integrado KBR36 sin necesidad de instalación de ningún driver.

Instalación del driver para lectores que comercializa Bit4Id.(Si tu lector no es de Bit4Id puedes saltar este apartado)
En el caso de los lectores comercializados por Bit4Id y en concreto el modelo miniLector ESSENTIA, hemos tenido más problemas ya que los drivers no vienen de serie con MacOS y por otro lado los drivers indicados en la web en http://www.bit4id.com/espanol/descargascontroladores.php  no están actualizados y no funcionan correctamente con las últimas versiones de MacOS. Afortunadamente estos problemas pueden ser solucionados descargando e instalando los drivers oficiales de http://www.acr38u.com/index.php?pos=drivers

Actualización Bit4Id: Aunque las pruebas las hemos realizado sólo sobre un conjunto reducido de lectores (los que teníamos a nuestro alcance), el fabricante Bit4Id nos informa que actualmente disponen de lectores compatibles con libccid como el miniLector Lite, por lo que debería funcionar correctamente sin la necesidad de instalación de drivers.

Instalación del driver para lectores de GEMPLUS.(Si tu lector no es de GEMPLUS puedes saltar este apartado)
Al igual que ocurre con los lectores de C3PO, los drivers necesarios ya están incluidos en MacOS por lo que podremos utilizarlos sin necesidad de ninguna instalación.

Instalar la librería para tarjetas inteligente (OpenSC)(Instalar estas librerías es necesario sea cual sea su lector de tarjetas) Una vez que tengamos instalado el driver para nuestro lector de tarjetas, será necesaria la instalación de la librería OpenSC, y aunque en las nuevas versiones MacOS ya se incorpora, en algunos casos puede ser necesario actualizar estas librerías. En concreto, para poder utilizar el DNIe en nuestro equipo tendremos que instar la versión de sca-0.2.3pre2 en caso de que se trate de un MacOS Leopard 10.5.x o la versión sca-0.2.2 para la versión MacOs Tiger 10.4.x.

Instalar los drivers para el DNIe.(Necesario para hacer uso del DNIe)
En el caso particular del DNIe, también será necesario la instalación del paquete opensc-dnie, que está disponible para su descarga en http://www.dnielectronico.es/descargas/PKCS11_para_Sistemas_Unix/index.html.

Una vez instalado ya podremos hacer uso del DNI electrónico en nuestro equipo.NOTA: Aunque existen versiones más recientes de OpenSC para MacOS, es necesario que se instale exactamente la versión indicada ya que en otro caso obtendremos el siguiente error: load_dynamic_driver: dynamic library ‘/Library/OpenSC/lib/libopensc-dnie.dylib’: invalid module version.Para más información se puede consultar el manual de instalación oficial del dnie.

Probamos nuestro nuestro lector con Viafirma
Para ello, con el DNIe ya introducido en nuestro lector, accedemos con Safai o Firefox a la demo de Viafirma .

Introducción

Mylyn-Mantis es un plugin que permite la integración en Eclipse con repositorios Mantis, de forma que se puede interactuar con un bugtracker Mantis directamente desde nuestro IDE, permitiendo:

• Crear incidencias
• Asignar incidencias
• Añadir comentarios
• Cambiar de estado incidencias
• Resolver incidencias
• Asociar un conjunto de código a una incidencia, a la hora de realizar un commit de código.

Utilización

Una vez que disponemos de un repositorio Mantis, podremos recuperar el conjunto de tareas de un proyecto, planificarlas, asignarlas, resolverlas, incorporar comentarios, asociar código fuente a las mismas…

Conexión a un repositorio

Gracias a Mylyn disponemos de dos nuevas vistas de interés:

• Task Repositories: en esta vista configuramos los distintos repositorios (por ejemplo, un servidor de Mantis) que almacenan proyectos/tareas.
• Task List: almacena tareas categorizadas de distintas formas (por ejemplo por proyectos).

Y como hemos dicho, gracias al plugin Mylyn-Mantis podemos utilizar Mantis dentro de Mylyn. Estas 2 vistas aparecen en la perspectiva “Planning”, perspectiva recomendada para trabajar con tareas.

En primer lugar deberíamos configurar el repositorio Mantis. Para ello necesitamos la vista Task Repositories. Esta vista podemos añadirla, si no la tenemos en nuestra perspectiva, a través de Window->Show View->Other, y desplegando la opción Mylyn. Dentro de esta vista, al hacer clic en el botón derecho del ratón nos aparece, entre otras, la opción de crear un nuevo repositorio de tareas (Add Task Repository):

Al escoger esta opción se nos solicita qué tipo de servidor queremos configurar. En el caso de Mantis escogeremos dicha opción:

Y se nos piden datos sobre el servidor de Mantis:

Deberemos conocer la URL del servicio SOAP de Mantis (Mantis-Connect), así como nuestro usuario y contraseña. En esta ventana podemos realizar una validación de la configuración, para comprobar que sea correcta antes de grabar. Una vez hayamos hecho esta comprobación, ya disponemos de una conexión a Mantis.

Consulta a un repositorio y descarga de incidencias

Para ello creamos una query al repositorio Mantis. Dentro de la vista Task List, botón derecho del ratón, escogemos la opción “New Query”:

Escogeremos nuestro repositorio de tareas (Mantis) y continuamos. Le damos un título al filtro (normalmente el del proyecto con el que estemos trabajando) y en el desplegable escogemos el proyecto y un filtro. Estos filtros son queries que deben haber sido definidas previamente; es necesario disponer de al menos un filtro definido en Mantis, ya sea público o privado (un usuario, tras hacer una búsqueda avanzada, puede guardar ese filtro y recuperarlo en este momento; por ejemplo, puede crearse un filtro para recuperar sólo las incidencias no resueltas asignadas a él).

Al grabar se nos crea esta consulta, y el plugin comienza un proceso de sincronización con el servidor Mantis para descargarse todas las incidencias que cumplan el filtro:

En cualquier momento podemos crear una nueva tarea dentro de Eclipse. Para ello, simplemente tenemos que invocar a New Task dentro de la vista Task List

Para crearla, nos pedirá primero en qué repositorio de tareas queremos grabarla (Mantis), luego pide el proyecto y se pulsa en Finish. Se llega a una ficha de la tarea donde podremos grabar sus datos. Esta ficha es idéntica a la que se observa al acceder al detalle de una tarea, donde podemos realizar prácticamente cualquier actividad sobre ella: cambiar su estado, asignación, dar comentarios, etc.

Trabajando con tareas

Como se ha comentado, se recomienda el uso de la perspectiva Planning En la ficha de una tarea (parte superior derecha) disponemos de una opción para Activar / Desactivar una tarea:

Al activar una tarea, le indicamos a Eclipse que todo el código que incluyamos hasta el momento se corresponde con esa tarea, asociando el mismo al contexto de dicha tarea.

Si volvemos a nuestra perspectiva de trabajo (por ejemplo Java o Java EE, vista Project Explorer) es posible que dejemos de ver nuestros ficheros, advirtiendo un mensaje “Empty task context, unfocus or Alt + click”. Esto es debido a que Eclipse incorpora la posibilidad de filtrar nuestros proyectos/ficheros viendo sólo aquellos que están incluidos (relacionados) en el contexto de la tarea seleccionada:

Simplemente pulsando sobre el icono de filtrado volveremos a ver todos los proyectos y ficheros, sin filtrar por el contexto de una tarea.

Esto por ejemplo provoca que se genere un comentario específico a la hora de hacer commit del conjunto de ficheros asociados al contexto de una tarea, muy útil para conocer qué tarea se ha resuelto con el conjunto de código entregado:

Planificando tareas

Eclipse nos permitirá planificar nuestras tareas asignadas en fechas, y nos avisará en pantalla en el momento en el que se supone que deberíamos desarrollar una tarea concreta.

* Sólo Chuck Norris puede hacer una clase  abstracta y final.
* Chuck Norris serializa los objetos directamente en cráneos humanos.
* Chuck Norris no despliega aplicaciones web, él las mete a patadas en el servidor.
* Chuck Norris siempre utiliza sus propios patrones de diseño, y su favorito es la Patada Voladora Chuck.
* Chuck Norris puede usar para matarte cualquier clase de java.util .* , incluido el javadocs.
* Chuck Norris puede golpear tan fuerte que tu aplicación web se convierta en una aplicación swing, y es muy probable que sea una aplicación swing con una gran cantidad de iconos de cráneos humanos.
* Chuck Norris demostró el significado de Float.POSITIVE_INFINITY contando hasta él, dos veces.
* La sincronización no protege frente a Chuck Norris, si quiere el objeto, él lo toma.
* Chuck Norris no usa javac, él edita directamente los .class con un editor binario.
* El código Java de Chuck Norris nunca necesita ser optimizado. Su código es tan rápido que rompió la velocidad de la luz durante una prueba en los laboratorios de Sun matando a 37 personas.
* Cuando alguien intenta utilizar un método deprecated hecho por Chuck Norris , el método no avisa de que está deprecado. Automáticamente te pega una patada voladora en la cara en tiempo de compilación.
* El paquete java.lang originalmente contenía una ChuckNorris clase, pero fue quitado del paquete durante la revisión ya que Bill Joy recibió una patada voladora en la cara.
* Chuck Norris no tiene un error en su código, EVER!
* Chuck Norris no escribe código. Él mira a la pantalla de un ordenador hasta que obtiene el PROGRAMA que quiere.
* El código funciona más rápido cuando Chuck Norris lo mira.
* Chuck Norris modifica binarios .class ignorando el verificador de bycodes de Java.
* Chuck Norris no captura excepciones porque nadie tiene el coraje para lanzar ninguna.
* Chuck Norris puede hacer un casting a cualquier objeto sólo mirándolo.
* Si usted recibe un ChuckNorrisException lo más probable es que muera.
* Chuck Norris es el único que puede utilizar GOTO y const en Java.
* Chuck Norris puede compilar el código Java en . NET Framework, evidentemente, sólo mirándolo.
* Chuck no necesita capturar ninguna excepción de Java porque cuando va a lanzar la excepción Java tiene miedo de su patada voladora.
* Los niveles de visibilida Java son public,default, protected, private y protected By Chuck Norris “, no intente tener acceso a un campo con este último modificador!
* Chuck Norris come crudos JavaBeans y da patadas voladoras a JavaServer Faces!
* Chuck Norris puede dividir por 0!
* Recolector de basura sólo se ejecuta sobre el código de Chuck Norris para recoger los cadáveres.
* Cada línea de código de Chuck Norris se ejecuta en tiempo real. Incluso en una aplicación multi-thread.
* Cuando una CRU carga un .class de Chuck Norris duplica la velocidad.
* Chuck Norris puede ejecutar instrucciones de 64 bits en una CPU de 32 bits.
* Chuck Norris implementa “Indestructible”. Todas las demás criaturas implementan “Killable”.
* Chuck Norris sólo programa aplicaciones web en Java para conseguir ganar el .WAR!
* Chuck Norris dio una vez una patada voladora a una clase Java. El resultado es conocido como las inner class.
* Chuck Norris puede hacer herencia múltiple en Java.
* JVM no arroja excepciones a Chuck Norris, ya no. Que matara a 753 ingenieros de Sun fue suficiente.
* Chuck Norris no necesita unidad de pruebas, porque su código siempre funciona. Siempre.
* Chuck Norris extiende a Dios. ( Y Dios que era final no pudo hacer nada para evitarlo)
* Chuck Norris tiene tanta memoria de trabajo y es tan poderoso que puede ejecutar todas las aplicaciones Java en el mundo y obtener el 2% de uso de los recursos.
* Chuck Norris ya usaba en su código genéricos en la versión 1.3.
* Una clase Chuck Norris no puede ser decompilada… no se moleste en intentarlo.

Traducción libre de: http://www.ovisual.com/4/

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:

<!--  Dependencias para el cliente viafirma con soporte de OpenID -->
<dependency>
 <groupId>org.viafirma</groupId>
 <artifactId>viafirma-client</artifactId>
 <version>[2.2.3,2.3.0)</version>
</dependency>

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

http://repositorio.viavansi.com/repo

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.

<%@page import=“org.viafirma.cliente.ViafirmaClientFactory”%>
<%@page import=“org.viafirma.cliente.ViafirmaClient”%>
<body>
<%
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ón</a></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(…):

public class ViafirmaClientResponseServlet extends ViafirmaClientServlet{
 @Override
 public void authenticateOK(UsuarioGenericoViafirma usuario,HttpServletRequest request, HttpServletResponse response) {
  // Lógica específica de la aplicación para gestionar el resultado de la autenticación 
  request.setAttribute(“usuarioAutenticado”, usuario);
  request.getRequestDispatcher(“/resultadoAutenticacion.jsp”).forward(request, response);
 }
 @Override
 public void cancel(HttpServletRequest request, HttpServletResponse response) {
   // Gestiónn de cancelaciónn del usuario al autenticar o firmar
   request.setAttribute(“error”, “El usuario ha cancelado la autenticación”);
   request.getRequestDispatcher(“/resultadoAutenticacion.jsp”).forward(request, response);
 }
@Override
public void error(CodigoError codError, HttpServletRequest request, HttpServletResponse response) {
  // Gestión de error al autenticar 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)