martes, 12 de enero de 2010

No se pudo encontrar la clase (VerifyError: Error #1014)

Hola a todos.

Una buena práctica a la hora de desarrollar con Flex es usar las RSLs (y en general en cualquier tecnología siempre que permita algo parecido), pero al usarlas es posible introducir ciertos errores que no son tan obvios y lo digo por experiencia personal. Me refiero al famoso error VerifyError Error #1014, este error llevaba un tiempo dándome la lata ya que usamos librerías compartidas entre varios proyectos y funcionaba en unos si y en otros no.

Con este panorama no queda otra que investigar un poco y resulta que el error es bien simple de solucionar. Este error se produce en tiempo de ejecución y se debe al orden de carga de las librerías, ya que si cargamos una librería A antes que otra B y A hace uso de B nos dará este error, ya que no encuentra las clases de B, porque no se han cargado.

Para solucionarlo tan solo debemos ir a nuestro proyecto y definir el orden correcto de las librerias.
  • Si usamos Flex Builder, pulsamos el botón derecho sobre el proyecto y vamos a propiedades (o Alt+Enter) --> "Flex Build Path" --> pestaña "Library path" y usamos los controles "Up" y "Down" para situar las librerías en el orden correcto.
  • O podemos modificarlo directamente en el fichero .actionScriptProperties en los tags

Personalmente, les recomiendo la primera opción por ser más simple, intuitiva y menos propensa a errores.

Saludos.

miércoles, 2 de diciembre de 2009

Aplicaciones: Exploradores Flex

Cualquier persona que haya trabajado con Flex se da cuenta enseguida de lo arduo que es tener que compilar y ejecutar la aplicación cada vez que se realiza un pequeño cambio de estilo un componente, etc. Estas pequeñas acciones suponen un pérdida de productividad a lo largo de la jornada de trabajo y por tanto son situaciones que deberíamos evitar a toda costa.

Para mejorar esta situación podemos usar algunas peuqeñas herramientas desarrolladas por y para la comunidad que nos permiten indagar en los componentes, cambiar sus estilos. Por esto mi intención es crear un directorio de herramientas de este estilo que sirva de referencia para encontrarlas. Por ahora tengo conocimiento de tres herramientas:
  • Adobe Flex 3 Component explorer: Desarrollado por Adobe. Es un catálogo de componentes básicos de Flex 3 que permite navegar por los componentes viendo ejemplos tanto visuales como de código. Es muy útil para hacernos a la idea de que componente usar o mostrarlos para que sean elegidos.
  • Adobe Flex 3 Style Explorer: Desarrollado por Adobe. Similar al anterior, pero en este caso nos brinda la posibilidad de aplicar estilos CSS a los componentes y comprobar el resultado en tiempo de ejecución, además va generando el CSS y permite exportarlo, con lo cuál podemos reutilizarlo en nuestra aplicación directamente. Es muy útil a la hora de crear estilos para nuestras aplicaciones.
  • Flex 3 Regular Expression Explorer: Desarrollado por Ryan Swanson. Es un navegador que nos permite crear y probar expresiones regulares. Asimismo, permite almacenar las expresiones para compartilas con el resto de la comunidad.
Probablemente ya conozcáis alguna o todas estas herramientas ya que algunas son muy conocidas. Si conocéis alguna otra herramienta de este estilo podéis comunicarlo e iremos confeccionando un listado.

Espero que os sea de utilidad, Saludos.

viernes, 16 de octubre de 2009

Site para el proyecto con Maven

Una buena práctica a la hora de publicar nuestros proyectos es, sin duda, crear un site para el proyecto en el que podamos añadir toda la información sobre el proyecto, desarrolladores, código fuente (en caso de desear compartirlo), informes sobre test, "issue tracking" y un sin fin de cosas. Es lógico que crear un site con toda está información desde cero es muy costoso, por tanto voy a proponer un sistema automático.

Para llevar a cabo esta automatización podemos usar el plugin de maven "Maven Site Plugin", el cuál generará el site automáticamente con toda la información que definamos en su configuración. Lo primero que debemos hacer es añadir el plugin en nuestro fichero pom.xml:

<project>
...
<build>
<!--Para usar las metas del plugin-->
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>2.0.1</version>
</plugin>
...
</plugins>
</build>
...
</project>


Si queremos definir el plugin en el pom padre para que sea usado por todos los proyectos hijos podemos usar esto:

<project>
...
<build>
<!-- Para definir el plugin en el POM Padre-->
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>2.0.1</version>
</plugin>
...
</plugins>
</pluginManagement>
...
</build>
...
</project>


Una vez que tenemos esto podemos ejecutar el comando mvn site para crear nuestro site, por defecto lo creara en la carpeta {basedir/target/site}. Obviamente el site generado tendrá la configuración por defecto y creará el contenido por defecto, estando la mayoría de la información sin rellenar. Algunos apartados puedes tener datos, como las dependencias o la información del proyecto y los desarrolladores, que serán extraídas del pom.


Configurar el site.
Para configurar el site a nuestro gusto e ir añadiendo la información que deseemos. En la carpeta src debemos crear la siguiente estructura:

+- src/
+- site/
+- apt/
| +- index.apt (versión por defecto)
|
+- site.xml (descriptor de la versión por defecto)


Para cambiar el ábol de navegación debemos configurar nuestro descriptor del site (site.xml), podemos ver como se crea un descriptor del fichero en la página oficial del plugin.


Configurar los informes
Podemos añadir los informes que generamos con otros plugins de maven. Hay muchos informes estándar disponibles que obtienen información del POM. Actualmente los que se proveen por defecto son los siguientes:
  • Informe de dependencias
  • Listas de correo
  • Integración Continua
  • Repositorio de código fuente
  • Seguimiento de errores (Issue Tracking)
  • Equipo del proyecto
  • Licencia.
Para añadirlos tan sólo debemos configuralos en la sección del POM y añadir las entradas correspondientes en el fichero site.xml, si esté ha sido modificado, ya que en el fichero por defecto se incluyen dichas secciones.

<project>
...
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-project-info-reports-plugin</artifactId>
<version>2.0.1</version>
</plugin>
</plugins>
</reporting>
...
</project>



Internacionalización.
La internacionalización de nuestro site es muy sencilla, tan sólo debemos configurar el plugin para que admita varios locales, añadiendo en la configuración del plugin:

<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>2.0.1</version>
<configuration>
<locales>en,es</locales>
</configuration>
</plugin>
</plugins>
</build>
...
</project>


Y luego crear una carpeta para el contenido para cada idioma, el contenido del idioma por defecto irá en la carpeta raíz y crearemos una carpeta para cada idioma extra. Asimismo crearemos un descriptor del site en cada idioma, sería algo así:


+- src/
+- site/
+- apt/
| +- index.apt (versión por defecto)
|
+- es/
| +- apt/
| +- index.apt (versión en español)
|
+- site.xml (descriptor de la versión por defecto)
+- site_es.xml (descriptor de la versión española)



Ejecución y despliegue del Site.
Una vez que tenemos nuestro site, podemos ejecutarlo usando nuestra máquina como servidor con el comando mvn site:run y podemos acceder a él en el puerto 8080 del localhost (http://localhost:8080/). Si disponemos de un dominio y almacenamiento para nuestro site podemos publicarlo automáticamente, para ello debemos añadir en nuestro POM la la información de la URL a la que subiremos el site, en la configuración del distributionManagement:

<project>
...
<distributionManagement>
<site>
<id>www.yourcompany.com</id>
<url>scp://www.yourcompany.com/www/docs/project/</url>
</site>
</distributionManagement>
...
</project>


y luego ejecutar el deploy, para ello tenemos dos opciones:
  • mvn site:deploy : Este comando sólo despliega el site, por tanto el sitio debe haberse generado antes.
  • mvn site-deploy : Si queremos ejecutar todo el proceso desde generarlo hasta su publicación debemos ejecutar la fase site-deploy del ciclo de vida.

Os dejo un proyecto de prueba vacío en el que se aplica todo esto, para generar un site.





Como vemos, con esta herramienta podemos ahorrar mucho tiempo y generar un site con toda la información del proyecto, en otra ocasión continuaremos con más buenas prácticas.

Saludos.

miércoles, 14 de octubre de 2009

Preview de Bonita Studio 5.0

BonitaSoft ha puesto en circulación la preview de BonitaStudio 5.0, la nueva versión de su herramienta BPM (Bussines Process Management), por ahora solo está disponible como preview privada, y solo pueden acceder a ellas los usuarios registrados en el nuevo site de BonitaSoft antes del 10 de Octubre de 2009.

Por la información expuesta en el site podemos decir que han rediseñado la interfaz y la funcionalidad, cosa que se agradece bastante ya que la versión 4.0 me desencanto un poco.

Particularmente he trabajado con la versión 3 y 4 de Bonita y entre ellas hubo una gran diferencia. La versión 4 de Bonita es relativamente nueva y quiso cambiar completamente el esquema de la antigua Bonita, y esta nueva versión 5.0 viene a cubrir todos los huecos que la versión 4 dejo descubiertos, como la Interfaz gráfica y la API que era bastante limitada si se compara con la de la versión 3.

Yo ya le he descargado pero desafortunadamente no he tenido tiempo de probarla, en cuanto la pruebe comentaré mis primeras impresiones. Realmente espero que con está nueva versión se solvente algunos de esos pequeños problemas ya que estamos ante una de las mejores soluciones BPM del momento.

jueves, 1 de octubre de 2009

Acceder a servicio SOAP tras un proxy con CXF

Si queremos acceder, con CXF, a un servicio SOAP a través de un Proxy puede suceder que falle la llamada, ya que el resultado que nos devuelve es "troceado", y por tanto al recibir el mensaje de retorno, este no cumple con el formato SOAP.

Nos mostrará un error al acceder a la URL en la que se encuentra el servicio, indicándonos el mensaje "Método de la petición y protocolo no soportados". En el caso de que el proxy sea Squid nos mostrará también el siguiente mensaje "Squid no admite todos los métodos para todos los protocolos de acceso. Por ejemplo, no se puede hacer un POST a un servidor Gopher".

El stackTrace provocado por el error es algo similar a similar a este:


Para solucionar este problemas debemos configurar el CXF para desactivar el "chunking" (troceado), para ello crearemos/modificaremos el fichero de configuración de CXF (por defecto cxf.xml), consistente en un conjunto de beans de Spring, en el que añadiremos o descomentaremos, si ya existe el fichero, lo siguiente:

Podemos ver como configurar el CXF en la sección de configuración de la página oficial de Apache.