Contar los días que hay entre dos fechas

A continuación se muestra una función que se podría utilizar para contar los días que hay entre dos fechas. El lenguaje utilizado es Java y se emplea el Calendar para facilitar la tarea.

    /**
     * @param desde - Date con la fecha inicial
     * @param hasta - Date con la fecha final
     * @return int - devuelve el total de días que hay entre las 
     *               dos fechas sin contar sábados ni domingos.
     */
private int devuelveDiasLaborables(Date desde, Date hasta){
     Calendar calendarDesde = Calendar.getInstance();
     calendarDesde.setTime(formatoFecha.parse(desde));		

     Calendar calendarHasta = Calendar.getInstance();
     calendarHasta.setTime(formatoFecha.parse(hasta));
     
     int contador = 0;	
     while (!calendarDesde.after( calendarHasta )) {
	
         if((calendarDesde.get(Calendar.DAY_OF_WEEK)!=Calendar.SATURDAY) &&
              (calendarDesde.get(Calendar.DAY_OF_WEEK)!=Calendar.SUNDAY)){
	      //si no es sábado ni domingo incrementamos la cuenta
	      contadorDias++;
         }					
         calendarDesde.add(Calendar.DAY_OF_MONTH, 1);//Siguiente día
     }
     return contador;
}

JRFontNotFoundException

Cuando al ejecutar un report nos encontramos con el siguiente error:
Mensaje: Font ‘Arial’ is not available to the JVM. See the Javadoc for more details.
Excepcion: net.sf.jasperreports.engine.util.JRFontNotFoundException: Font ‘Arial’ is not available to the JVM. See the Javadoc for more details.

Si no queremos añadir un jar con la fuente (Arial en este caso). Una de las formas que se puede emplear para corregirlo consiste en, simplemente, añadirle la propiedad
net.sf.jasperreports.awt.ignore.missing.font = true
Con esto evitamos que lance la excepción ya que sustituirá la fuente Arial por otra que sí esté disponible.

Nota: Más información aquí.

Transacciones con Spring AOP (Forma declarativa con un fichero xml)

El tratamiendo de las transacciones mediante Spring AOP puede realizarse de varias formas. O bien, de forma programática o bien de forma declarativa (ya sea con anotaciones o con fichero xml):


1/ Si se hace de forma programática, las transacciones, deben controlarse en las distintas clases. Esto puede llegar a resultar bastante engorroso en aplicaciones relativamente grandes.


2/ Si se hace de forma declarativa con anotaciones estaríamos en la misma situación ya que las transacciones se definen dentro de las propias clases como antes, eso sí, de una forma más limpia.


3/ Si se hace de forma declarativa con un fichero xml se puede poner un punto de corte (pointcut) sobre la capa manager que abarque a todas las clases pertenecientes a ella. Y mediante un se pueden definir los tipos de propiedades de las transacciones (propagation, isolation leven, timeout, etc.), que deben ejecutar los métodos de esas clases manager. Para ello basta con seguir algún patrón a la hora de nombrar los nombres métodos y así poder diferenciarlos unos de otros. De esta forma en unas pocas líneas de un fichero xml se tienen tratadas todas las transacciones de la aplicación.




Para usar esta tercera forma nos pide aparte un par de librerías de Aspectj. Obtenidas p.e. de maven, de la siguiente forma:

      
          org.aspectj
          aspectjrt
          1.5.4
      
      
          org.aspectj
          aspectjweaver
          1.5.4
      

Un ejemplo sencillo de uso, con hibernate:

Nota: Aquí hay bastante más información para consultar http://static.springsource.org/spring/docs/2.5.x/reference/aop.html

Test does not support runtime expressions

Programando unas jsp me he encontrado con una serie de ‘warnnings’. Aunque al ejecutarlas bajo un tomcat funcionaban correctamente, en un OAS daban problemas. Los ‘warnnings’ en cuestión eran tal que así:

Esto sucedía porque estaba importando la taglib de JSTL 1.0 en lugar de su versión 1.1.
Utilizaba:

<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>

En lugar de:

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"  %>

Como se puede ver, las dos URI’s se parecen mucho y es bastante fácil equivocarse.