Actualizar Zonas Horarias en Java

Para actualizar las zonas horarias en Java, se debe descargar la última versión de la herramienta TZ Updater Tool, desde la ruta:

http://www.oracle.com/technetwork/java/javase/downloads/index.html

Luego, se debe ejecutar esta herramienta (que es un simple JAR), desde la línea de comandos. Para esto, se debe ejecutar cmd.bat COMO ADMINISTRADOR (buscar el comando, botón derecho, Ejecutar como Administrador). Esto porque en Windows 7, cualquier cambio en las carpetas de programas requiere permisos de administrador.

A continuación, posicionarse en la carpeta bin de la versión de Java que se quiera actualizar (en el caso que haya más de una versión de Java instalada en la máquina) y ejecutar:

java -jar E:\SOFTWARE\Java\tzupdater-2_0_0-2015a\tzupdater.jar -t

donde "E:\SOFTWARE\Java\tzupdater-2_0_0-2015a\tzupdater.jar" es la ubicación del JAR descargado. El parámetro "-t" significa "test". Si hay errores, debiera salir una lista de test fallidos. 

Para actualizar, ejecutar:

java -jar E:\SOFTWARE\Java\tzupdater-2_0_0-2015a\tzupdater.jar -u

Luego, nuevamente ejecutar el test:

java -jar E:\SOFTWARE\Java\tzupdater-2_0_0-2015a\tzupdater.jar -t

Si la actualización fue correcta, esta vez no debiera salir ningún mensaje, lo que significa que las zonas horarias están actualizadas.

Importar Configuración DB2 desde un PC a otro

Para importar la configuración de bases de datos a un nuevo PC (proceso largo y tedioso cuando son muchas bases de datos) existen dos utilidades de DB2: db2cfexp (para exportar la configuración a un archivo)  y db2cfimp (para importar la configuración desde un archivo):

1. En el PC de origen, ir a DB2 -> DB2COPY -> Herramientas de Línea de Mandatos -> Procesador de Línea de Mandatos:
1. db2 => quit
2. db2cfexp e:\software\template.txt TEMPLATE
2. Copiar el archivo recién creado (template.txt) en el PC de destino
3. En el PC de destino, ir a DB2 -> DB2COPY -> Herramientas de Línea de Mandatos -> Procesador de Línea de Mandatos
1. db2 => quit
2. db2cfimp e:\software\template.txt

Identificación de Excepciones SQL

Cuando el log del servidor de aplicaciones lanza un error de este tipo:


... Caused by: com.ibm.db2.jcc.a.SqlException: DB2 SQL error: SQLCODE: -407, SQLSTATE: 23502, SQLERRMC: TBSPACEID=3, TABLEID=27, COLNO=2

nos gustaría saber a qué tabla y columna específica se refiere este error. Existen dos tablas que contienen esta información:

SYSCAT.TABLES y SYSCAT.COLUMNS

Para el ejemplo anterior, las sentencias que nos entregan la información deseada son:

SELECT TABNAME FROM SYSCAT.TABLES WHERE TABLEID=27 AND TBSPACEID=3;

y luego:

SELECT * FROM SYSCAT.COLUMNS WHERE COLNO = 2 AND TABNAME = [TABNAME];

donde [TABNAME] es el nombre de la tabla, que dio resultado la primera consulta.

Manejo de Excepciones en EJB 3

¿Debiera una transacción retrotraerse cuando se lanza una excepción y ésta no se captura? En EJB 2, sólo se retrotrae automáticamente la transacción en el caso de excepciones no chequeadas (subclases de RuntimeException). Para lograr el mismo resultado con excepciones chequeadas, era necesario capturar dichas excepciones, marcar manualmente la transacción como "fallida" y luego relanzar la excepción:


        } catch (AccessDeniedException e) {
            getSessionContext().setRollbackOnly();
            throw e;
        }
        ...

En EJB 3, esto ya no es necesario, ya que existe la posibilidad de definir esto en la misma excepción:

        @ApplicationException(rollback=true)
        public class ServiceException extends Exception {...

de esta manera, el contenedor EJB sabe que, de lanzarse este tipo de excepciones y no ser capturadas, la transacción activa debe retrotraerse.

Más información:

http://today.java.net/article/2006/04/04/exception-handling-antipatterns

Bienvenida

Este es mi primer posteo, espero publicar información útil y una que otra opinión.