Archivo de la categoría: Uncategorized

Sonar – Maven: A required class was missing

Me estoy pegando desde ayer para integrar nuestro actual proyecto con Sonar, para poder realizar pruebas de cobertura y mostrar estadísticas de infracciones de código, y tras la instalación de Sonar en local me he encontrado un problema al ejecutarlo las primeras veces.

Tras la instalación, al lanzar por primera vez Sonar con:

mvn sonar:sonar

obtenía errores al faltarme librerías, que no estaban en nuestro repositorio y he tenido que ir bajándome de MVNRepository, para luego instalarlas en nuestro Artifactory.

Tras incluir todas las librerías necesarias, al lanzar el comando me he encontrado con el siguiente error:

[ERROR] Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar
(default-cli) on project tbs: Execution default-cli of goal
org.codehaus.mojo:sonar-maven-plugin:2.0:sonar
failed: A required class was missing while executing
org.codehaus.mojo:sonar-maven-plugin:2.0:sonar:
Ljavax/persistence/EntityManagerFactory;

En principio no debería de producirse, ya que se supone que al descargar los JARs y subirlos, estos incluyen el pom con las dependencias sobre otras librerías.

Pero ha dado la casualidad de que para la librería plexus-classworlds-2.2.3 su pom está mal y necesita que incluyamos dos dependencias más: persistence-api-1.0 y javassist (yo he incluido la última versión: 3.12.1.GA).

De esta forma, el pom queda así:

  <dependencies>

    <dependency>

      <groupId>junit</groupId>

      <artifactId>junit</artifactId>

      <version>3.8.2</version>

      <scope>test</scope>

    </dependency>
    <dependency>
      <groupId>javax.persistence</groupId>
      <artifactId>persistence-api</artifactId>
      <version>1.0</version>

      <scope>compile</scope>

    </dependency>
    <dependency>
    <groupId>javassist</groupId>
    <artifactId>javassist</artifactId>
    <version>3.12.1.GA</version>

      <scope>compile</scope>

    </dependency>
  </dependencies>

Tenerlo en cuenta por si os encontráis con el mismo problema.

En caso de que la clase que os falte sea otra y no sepáis desde dónde se hace referencia, lanzar el comando en modo debug:

mvn sonar:sonar -X

Revisar las trazas y además del nombre de la clase que necesitáis, tomar nota de la clase donde se está invocando a la misma, como en este ejemplo:

A partir de aquí, primero tendréis que averiguar, tirando de Google, a qué librería pertenece la clase que os falta, y después en cuál de las que habéis incluido se encuentra la clase que la usa.

En mi caso la clase javax.persistence.EntityManagerFactory se encuentra en persistence-api-1.0.jar, así que lo busco en algún repositorio de Maven y lo subo a mi artifactory.

Y la clase que la requiere se encuentra en plexus-classworlds-2.2.3, así que me descargo el pom del Artifactory y lo modifico para incluir la dependencia que necesito, volviendo a subir el pom al Artifactory.

Una vez hecho, borro mi repositorio local, para forzar que se lo vuelva a descargar, y compruebo si necesito alguna dependencia más o ya funciona Sonar.

Un pequeño ejemplo con JAXB.

JAXB, acrónimo de ‘Java Architecture for Xml Binding‘, es un API para convertir objetos Java en xml y leer esos mismos xml para obtener objetos Java, que desde la versión 7 tenemos disponible en nuestros JDKs.

Recientemente nos surgió la necesidad, en uno de los proyectos en los que trabajo, de poder guardar ‘evidencias’ de objetos durante la ejecución de una serie de programas a modo de registro para poder analizar el comportamiento y evolución de una serie de datos calculados.

La primera idea para hacer esto sería el escribir un método ‘toString’ que nos devuelva los valores del objeto de tal forma que los podamos ir volcando a uno o varios ficheros, para luego poder analizarlos.

Pero fue esa misma necesidad de poder analizarlos posteriormente la que me hizo pensar en hacer algo más elaborado, de forma que no solo pudiésemos obtener una representación de cada objeto en un momento dado, si no también poder luego explotar esa información desde nuestro aplicación de análisis.

Así fue como decidí tirar de JAXB, ahora que se ha incorporado a Java 7, pensando en obtener una representación que no dependiese de formatos propios y fuese fácilmente explotable.

La ventaja de JAXB reside en su capacidad de realizar ‘marshal’ y ‘unmarshal’ de objetos Java de forma directa, mediante el uso de anotaciones para indicar qué campos son los que queremos incluir en el xml, de una forma rápida, sencilla y no dependiente de un esquema.

El no depender de un esquema nos aporta además la ventaja añadida de poder realizar cambios sobre los objetos sin necesitar de realizar cambios en el parser que usáramos para convertir a xml y viceversa.

Para ver lo sencillo que es, planteemos un ejemplo.

Supongamos que tenemos una Clase Empresa:

package com.art4software.java.jaxb.example.po;

import java.util.ArrayList;

import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;

import com.art4software.java.jaxb.example.MarshalClass;

@XmlRootElement
@XmlType (propOrder = { "nombreEmpresa", "idEmpresa", "direccion", "numEmpleados", "empleados" })
public class Empresa extends MarshalClass {

	private int idEmpresa;
	private String nombreEmpresa;
	private String direccion;
	private int numEmpleados;
	private ArrayList<Empleado> empleados;

	public int getIdEmpresa() {
		return idEmpresa;
	}

	@XmlElement
	public void setIdEmpresa(int idEmpresa) {
		this.idEmpresa = idEmpresa;
	}

	public String getNombreEmpresa() {
		return nombreEmpresa;
	}

	@XmlElement
	public void setNombreEmpresa(String nombreEmpresa) {
		this.nombreEmpresa = nombreEmpresa;
	}

	public String getDireccion() {
		return direccion;
	}

	@XmlElement
	public void setDireccion(String direccion) {
		this.direccion = direccion;
	}

	public int getNumEmpleados() {
		return numEmpleados;
	}

	@XmlElement
	public void setNumEmpleados(int numEmpleados) {
		this.numEmpleados = numEmpleados;
	}

	public ArrayList<Empleado> getEmpleados() {
		return empleados;
	}

	@XmlElement
	public void setEmpleados(ArrayList<Empleado> empleados) {
		this.empleados = empleados;
	}
}

Como podemos ver nuestra Empresa tiene Empleados:

package com.art4software.java.jaxb.example.po;

import java.util.Date;

import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;

import com.art4software.java.jaxb.example.MarshalClass;

@XmlRootElement(name="Empl")
public class Empleado extends MarshalClass{

	private int id;
	private String nombre;
	private String titulo;
	private boolean activo=false;
	private Integer numeroEmpl;
	private Date fechaAlta;

	public int getId() {
		return id;
	}

	@XmlElement
	public void setId(int id) {
		this.id = id;
	}

	public String getNombre() {
		return nombre;
	}

	@XmlElement
	public void setNombre(String nombre) {
		this.nombre = nombre;
	}

	public String getTitulo() {
		return titulo;
	}

	@XmlElement
	public void setTitulo(String titulo) {
		this.titulo = titulo;
	}

	public boolean isActivo() {
		return activo;
	}

	@XmlElement
	public void setActivo(boolean activo) {
		this.activo = activo;
	}

	public Integer getNumeroEmpl() {
		return numeroEmpl;
	}

	@XmlElement
	public void setNumeroEmpl(Integer numeroEmpl) {
		this.numeroEmpl = numeroEmpl;
	}

	public Date getFechaAlta() {
		return fechaAlta;
	}

	@XmlElement
	public void setFechaAlta(Date fechaAlta) {
		this.fechaAlta = fechaAlta;
	}

}

Si os fijáis usamos 3 anotaciones: XmlRootElement, XmlType y XmlElement.

La primera marca el elemento raíz de nuestra clase (en nuestro caso el nombre de la clase). Con XmlType y la propiedad ‘propOrder’ cambiamos el orden en que se escribirán los atributos en el xml resultante.

Finalmente usando XmlElement en el setter de los atributos que nos interesa que se incluyan en el xml, marcamos los campos de nuestro interés.

Si os fijáis, ambas clases heredan de una tercera clase: MarshalClass.

¿Y para qué?

En mi caso, dado que la acción de guardar ‘evidencias’ se realizará sobre clases distintas, con esta herencia puedo limitar a un tipo común el manejo de las clases a guardar, haciendo que hereden de dicha clase el método de guardado:

package com.art4software.java.jaxb.example;

import java.io.File;
import java.io.FileWriter;
import java.io.IOException;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Marshaller;

public class MarshalClass {

	public void generateXML (String nameFile) {

		try {
			File file = new File (nameFile);
			JAXBContext jc = JAXBContext.newInstance(this.getClass());
			Marshaller jaxbMarshaller = jc.createMarshaller();

			jaxbMarshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);

			jaxbMarshaller.marshal(this, new FileWriter(nameFile, true));

		} catch (JAXBException e) {
			e.printStackTrace();
		} catch (IOException e) {
			e.printStackTrace();
		}
	}
}

Si os fijáis en el código del método, que será común para todos, realizar el Marshal es tan sencillo como:

  1. Obtener un JAXBContext sobre la clase a representar en xml (en nuestro caso).
  2. A partir de este contexto crear un ‘Marshaller’
  3. Configurar el formato de salida.
  4. Invocar al método para escribir la clase a xml.

En mi ejemplo uso un FileWriter en lugar de un File (cuya declaración he dejado en el ejemplo aunque no se usa) porque así podría ir volcando todas las representaciones a un único fichero, donde se iría añadiendo el xml de cada clase en cada invocación.

Si usáramos el File, estaríamos machacando el contenido si usamos el mismo nombre de fichero, o generando un nuevo fichero por cada invocación usando nombres distintos.

Ahora, para ejecutarlo:

package com.art4software.java.jaxb.example;

import java.util.ArrayList;
import java.util.Date;

import com.art4software.java.jaxb.example.po.Empresa;
import com.art4software.java.jaxb.example.po.Empleado;

/**
 *
 * @author mvcarrillo
 *
 */
public class JAXBExample {

	/**
	 * @param args
	 */
	public static void main(String[] args) {

		marshallingExample();

	}

	/**
	 * Crea una empresa y 10.000 empleados.
	 */
	private static void marshallingExample () {

		long time = System.currentTimeMillis();
		System.out.println ("Inicio: " + new Date(time));
		Empresa cc = new Empresa ();
		cc.setIdEmpresa(1);
		cc.setDireccion("En la nube");
		cc.setNombreEmpresa("Art4Software");
		cc.setNumEmpleados(25000);

		ArrayList<Empleado> alCU = new ArrayList<Empleado> ();
		int init = 20000;
		for (int i=1;i<10000;i++) {
			Empleado cu = new Empleado ();
			cu.setId(i);
			cu.setActivo(true);
			cu.setNumeroEmpl(new Integer (init++));
			cu.setNombre("Empleado " + i);
			cu.setTitulo("SW Architect");
			cu.setFechaAlta(new Date(System.currentTimeMillis()));

			alCU.add(cu);
		}

		cc.setEmpleados(alCU);

		long time2 = System.currentTimeMillis();

		System.out.println ("Generacion: " + (time2-time) + " milisegundoss - Marshaling: " + new Date (time2));

		cc.generateXML("Art4Software-Datos.xml");

		long time3 = System.currentTimeMillis();

		System.out.println ("Fin: " + new Date(System.currentTimeMillis()) + " - Tiempo Total: " + (time3 - time) + " milisegundos");

	}
}

Para realizar la conversión de todos los objetos, tan solo necesitamos invocar al método sobre el objeto ‘Empresa’, sin tener que hacerlo por cada objeto del tipo ‘Empleado’ que pueda contener en el ArrayList.

Como podéis ver, hemos metido unas trazas para ver cuánto tiempo tarda en realizar la creación de los objetos y el volcado a xml, obteniendo los siguientes tiempos (con JDK 1.7u21, eclipse Indigo, en un PhenomII x6 1090T con 8GB RAM):

Inicio: Fri Jun 07 22:38:56 CEST 2013
Generacion: 29 milisegundoss – Marshaling: Fri Jun 07 22:38:56 CEST 2013
Fin: Fri Jun 07 22:38:57 CEST 2013 – Tiempo Total: 312 milisegundos

Menos de medio segundo es un tiempo realmente bueno para lo que necesitamos realizar.

Ahora, a partir de aquí podríamos crearnos una aplicación que cargase un xml, o los xml contenidos en un directorio para una fecha concreta, y obtuviese todos los objetos grabados de nuevo para analizar los resultados.

Por último, importante tener en cuenta la siguiente tabla con la equivalencia de tipos de datos:

JAXB - Tabla Datos

Correspondencia de datos por defecto.

Truco: Solucionar error rtorrent en Raspberry Pi

Estos días atrás estuve trasteando, al fin, con mi Raspberry Pi.

El puente y el post que Javier Pastor publicó en su blog, Incognitosis, me animó a dedicar un rato a montar el Raspberry Pi con un cliente Torrent, además de un MySQL para usarlo como pequeño (muy pequeño) servidor casero.

Pero tras ponerlo en funcionamiento, aprovechando un viejo disco por USB de 2.5″ que tenía por casa, terminé encontrándome con un problema al cabo de un tiempo, que provocaba que el cliente de Torrent (rtorrent) terminase fallando.

rtorrent: page allocation failure: order:3, mode:0x20

Con el problema añadido de dejar el fichero de sesiones bloqueado y no permitiendo que el script de reinicio pudiese volver a arrancarlo.

Tras investigar un poco, encontré un foro donde un usuario indicaba que el problema parecía estar en la activación (en el fichero de configuración .rtorrent.rc) del uso de DHT.

Así que ayer procedí a cambiarlo y hoy he podido comprobar, tras más de 24h encendido, que de momento el problema no se ha vuelto a reproducir.

Por cierto, acaban de anunciar que el modelo B de Raspberry Pi ha sufrido una ampliación de RAM de los 256MB a los 512MB, manteniendo el precio de 35$, lo que lo hace aún más apetecible.

Actualización: pues el error se ha reproducido, es menos habitual pero aún hay fallos. Toca seguir investigando.

 

Edito: 06 noviembre 2012

Tras investigar un poco por los foros de Raspberry, el error apunta a un problema en el kernel de linux que estamos usando o un problema con los drivers USB, que provocaría un error ante condiciones de carga de CPU y uso intensivo del disco duro:

Kernel paging error during heavy network and disk load

 

I have an external, self powered 300gb NTFS drive mounted using ntfs-3g to /mnt/sda1. I am also running rtorrent in a background screen session using the recommended init.d startup script. rtorrent is configured to use ~/rtorrent/watch and ~/rtorrent/session as it’s watch and session directories (which are located on the sd card), and /mnt/sda1/rtorrent/downloads as the primary download directory.

After 30 mins or so of downloading a single torrent at ~1MB/s,
the Raspi crashes and I get the message:

Unable to handle kernel paging request at virtual address 8e78b8a2
pgd =cb9e4000
*pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT
Entering kdb (current0xca4ec520, pid 1313 Oops: (null) due to oops @ 0xc024d3d4

Incluso algún usuario apuntaba al modo ‘Turbo’ habilitado en la última versión, que haría que se usara más CPU para mejorar el tráfico de red:

setting to stabilize the official image

Please add «smsc95xx.turbo_mode=N» to /boot/cmdline.txt in the official image, it prevents the rpi from crashing under load.
Also prevents the log from filling with this:

CODE: SELECT ALL

smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped

by El_Presidente » Thu Aug 16, 2012 5:13 pm
OK – so I’ve done my own Googling and find that the turbo mode is meant to make the Ethernet more efficient but at the cost of using more Kernel memory. Putting this together with comments from around the Pi forum, it looks like the turbo mode grabs too much resource when heavily using the network, leading to kevent drops and page allocation issues. Others believe that because the Ethernet is effectively a port off the USB 3-port hub built into the Pi, it is flooding the whole USB subsystem, thus being a contributor to overall crap USB experience as well as kernel panic/crash.

Lo cierto es que con unas opciones u otras los errores se siguen produciendo, aunque al menos en esta última ocasión parece que con modo turbo anulado ha sido más estable y ha aguantado más tiempo en ejecución.