Error adquiriendo fuentes de datos en jDeveloper 11

En los últimos días he estado lidiando con un problema trabajando con jDeveloper 11.1.1.3.0. Estaba desarrollando una aplicación utilizando ADF y EJB, que venía funcionando correctamente. Sin embargo, un buen día, al arrancar el servidor, sin haber realizado cambios desde la última vez, me encuentro que mi aplicación lanza la siguiente excepción:

Exception [EclipseLink-7060] (Eclipse Persistence Services - 2.0.2.v20100323-r6872): org.eclipse.persistence.exceptions.ValidationException
Exception Description: Cannot acquire data source [java:/app/jdbc/jdbc/TareasDS].
Internal Exception: javax.naming.NameNotFoundException: While trying to look up /app/jdbc/jdbc/TareasDS in /app/ejb/ModelEJB.jar#TareasSessionEJB.; remaining name '/app/jdbc/jdbc/TareasDS'
at org.eclipse.persistence.exceptions.ValidationException.cannotAcquireDataSource(ValidationException.java:451)
at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:116)
at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:94)
at org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:162)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.loginAndDetectDatasource(DatabaseSessionImpl.java:584)
...
...
...
Caused by: javax.naming.NameNotFoundException: While trying to look up /app/jdbc/jdbc/TareasDS in /app/ejb/ModelEJB.jar#TareasSessionEJB.; remaining name '/app/jdbc/jdbc/TareasDS'
at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:1139)
at weblogic.jndi.internal.ApplicationNamingNode.lookup(ApplicationNamingNode.java:144)
at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:254)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:393)
at weblogic.jndi.factories.java.ReadOnlyContextWrapper.lookup(ReadOnlyContextWrapper.java:45)
at weblogic.jndi.internal.AbstractURLContext.lookup(AbstractURLContext.java:135)
at javax.naming.InitialContext.lookup(InitialContext.java:396)
at org.eclipse.persistence.sessions.JNDIConnector.connect(JNDIConnector.java:110)
... 204 more

Este error indica que la aplicación está tratando de acceder al DataSource indicado en el fichero persistence.xml, pero no lo consigue. Por tanto lo primero que uno puede pensar es que el fallo tiene que venir de algún problema de configuración de ese fichero, y empezar a editarlo: quitando el doble /jdbc, añadiendo y eliminando propiedades... Sin embargo no van por ahí los tiros.

A la hora de desplegar una aplicación en el servidor de aplicaciones WebLogic embebido de jDeveloper, éste crea fuentes de datos basándose en las conexiones configuradas por el usuario, que se pueden ver en la pestaña Database Navigator (si no la veis junto al Application Navigator podéis mostrarla mediante el menú View - Database - Database Navigator).

Pues bien, en mi caso el problema se debía a que, por algún motivo, la contraseña había desaparecido de las propiedades de la conexión que había configurado para mi aplicación. Bastó volver a introducirla y redesplegar la aplicación para que todo volviese a funcionar como siempre.

Sólo queda averiguar qué fue de la contraseña.

Tutorial de Swing Application Framework publicado en JavaHispano

La Asociación JavaHispano ha tenido el detalle de publicar un tutorial que he realizado en el que se desarrolla una pequeña aplicación utilizando el Swing Application Framework.

Este framework, desarrollado en la JSR-296, proporciona la infraestructura necesaria para la construcción de aplicaciones de escritorio con Java, incluyendo:

- Ciclo de vida

- Gestión de recursos (mensajes, imágenes, fuentes de texto...)

- Acciones

- Sesión (permite guardar el estado de la aplicación entre ejecuciones)

Actualmente la JSR se encuentra inactiva, por lo que el framework tal cual está condenado a morir. Sin embargo, creo que en su última versión ofrece suficientes cosas como para ser una buena opción a la hora de empezar a trabajar con Swing; y, por otro lado, la idea de crear un framework para esta tecnología sí sigue viva, y seguirá desarrollándose, seguro, en nuevos proyectos que partirán de SAF. Como muestra, Better SAF o guts-gui.

En esta página de JavaHispano podéis descargar el tutorial.

Muchas gracias a JavaHispano, y en concreto a Peyrona, Leonardo, Isaac, y revisor1 por su colaboración, y por haber mejorado sustancialmente el resultado final.

¡Viva España!

No es que me haya dado un arranque patriótico ni nada por el estilo. Lo que pasa es que hoy toca un terrorífico capítulo protagonizado por nuestra querida amiga la eñe (ñ).

El mundo de las letras no es muy distinto del nuestro: hay letras grandes y pequeñas, que están hasta en la sopa y que no encuentras si no es en kilómetros, que se alían para sus chanchullos, y hasta las hay mudas. Por tanto no hay que extrañarse si decimos que también hay letras marginadas, exluídas e ignoradas.

En este grupo se encuentran, mayormente, todas las letras que no son utilizadas por el rey de los lenguajes, el de iu es ei, el inglish. Por tanto, para nosotros los españoles, tenemos la á, é, í, ó, ú y, sobre todo, la ñ. De España.

Y si hay un contexto en el que se maximiza la discriminación hacia estas letras, ese es el informático. Todos hemos sufrido alguna vez las consecuencias de ser fieles a nuestra rica lengua incluyendo en algún código acentos y eñes. Sería interesante cuantificar la cantidad de horas que se han empleado en este mundo en estudiar errores que finalmente eran causados por los denominados caracteres extraños, y daría para hablar de lo importante que es pararse a pensar antes de hacer las cosas (lo digo por los que crearon las primeras codificaciones), pero vamos a centrarnos.

En este post simplemente voy a exponer un nuevo caso, que además puede afectar incluso a aquellos pobres hombres que, como yo, ya han renunciado a utilizar su idioma en todo su esplendor y hace anyos que abdicaron.

Ubiquémonos. Estamos trabajando con la suite de BI Pentaho. Accedemos a la consola de usuario, y de ahí a la creación de un nuevo informe. Entre las fuentes de datos podemos ver las que la herramienta trae, pero nosotros queremos crear una nueva, así que pulsamos el botón Add. En el diálogo, damos un nombre, escribimos una consulta, previsualizamos, añadimos, damos un nombre a mostrar, y aceptamos como si nada. Y entonces...

¡Aparece el mensaje!

(There are either no Data Source(s) defined in the metadata, or you do not have permission to access any of the Data Source(s). Please create one or more Data Source(s) using the Metadata Editor and then publish them to the Pentaho Server. Or, use the Metadata Editor to give the appropiate user permission to access to the Data Source(s).)

Que en la lengua de Cervantes, y con la capacidad de síntesis de Pocholo, significa que no hay fuentes de datos. Tras ello, un nuevo mensaje.

(pentaho-ajax.js.pentahoResponse():TypeError:'null' is null or not an object)

Que no se puede traducir a ninguna lengua seria.

Y ahora nos encontramos con que en la lista de fuentes de datos no hay niente. Pourquoi??

Cerramos el reporte, volvemos a acceder para crear otro desde cero... y la misma historia. ¿¿¿Qué ha pasado con las fuentes de datos???

Pues realmente no ha pasado nada. Están ahí. El problema es que Pentaho sigue un curioso comportamiento. No tiene problema en escribir una eñe, pero le da la risa cuando tiene que leerla, y se queda tonto.

Cuando creamos una fuente de datos, Pentaho crea un fichero de dominio en la ruta %Pentaho_Base%/server/bi-server/pentaho-solutions/system/metadata/domains, con el nombre que le hayamos dado. En ese fichero, con formato xml, se define la fuente de datos: conexión, consulta, etc, etc, etc. Si accedemos a esa ruta, veremos que, efectivamente, hay un fichero de definición con el nombre que le dimos a nuestra fuente de datos. Pero si lo abrimos... ¡ahí está! ¡La repudiada eñe!. En la descripción del locale Pentaho ha puesto Español (España), con todas las letras. Y ahora no es capaz de procesar el fichero.

Así que la solución inmediata es tan simple como editar el fichero .domain y quitarle el tupé a la eñe. Sólo con eso podremos crear de nuevo un informe y tendremos tanto las fuentes de datos de Pentaho como la que nosotros hemos creado, y podremos seguir con el proceso.

Otra posible solución es mudarnos a Estados Unidos, o instalarnos un Sistema Operativo en inglés.

Este problema no es exclusivo de la creación de informes; se da exactamente igual al crear dashboards.

Pero bueno, no nos quejemos. Peor lo deben tener los chinos...

4F530E43505002EF

Ese críptico código es el que nos encontramos hace unos meses, junto con un mensaje de error no mucho más elocuente en el log de nuestro servidor de aplicaciones OAS 10.1.2.0.2.

Unexpected Signal : 11 occurred at PC=0xB7D49B2D 

Function=(null) 

Library=[...]/jdk/jre/lib/i386/server/libjvm.so 

NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. 

Heap at VM Abort: 

Heap 

def new generation total 3392K, used 1221K 

eden space 3072K, 33% used 

from space 320K, 63% used 

to space 320K, 0% used 

tenured generation total 29264K, used 18790K 

the space 29264K, 64% used 

compacting perm gen total 29184K, used 29050K 

the space 29184K, 99% used 

Elapsed Time = 1602 

# 

# HotSpot Virtual Machine Error : 11 

# Error ID : 4F530E43505002EF 

# Please report this error at 

# http://java.sun.com/cgi-bin/bugreport.cgi 

# 

# Java VM: Java HotSpot(TM) Server VM (1.4.2_06-b03 mixed mode) 

# 

# An error report file has been saved as hs_err_pid20003.log. 

# Please refer to the file for further information. 

#

Cuando uno se encuentra con este tipo de errores sufre un repentino estado de ansiedad y se acuerda de aquel lejano día en que se decantó definitivamente por la informática como profesión.

Aunque en realidad el tema parece claro: ha habido un error de la máquina virutal de Java, ésta ha cascado irremediablemente, y tu aplicación se ha quedado tostada con el consiguiente cabreo del sufrido usuario.

Y en este caso, ¿podemos hacer algo aparte de largarle el problema a nuestro amigo Larry? (es lo que tiene comprar empresas, que te las llevas con lo bueno y lo malo).

Pues sí, podemos.

Lo que tenemos ante nosotros es la consecuencia de uno de los habituales bugs informáticos, que se resuelve con una actualización de versión de la JVM. Para este error concreto era necesario pasar de la 1.4.2_06-b03 a la 1.4.2_26_b07 (por contextualizar, se trata de una aplicación basada en ADF-UIX)

Para actualizar la JVM de una instancia de OAS ya instalada, lo que tenemos que hacer es seguir estos sencillos pasos.

- Instalar la nueva versión en la ruta .../oracle/product/10.1.2.0.2/midtier_1/j2ee/nombreInstancia/jdk.

- Modificar, a través del Enterprise Manager, la propiedad Ejecutable java de la instancia en cuestión, apuntando a la ruta 

.../oracle/product/10.1.2.0.2/midtier_1/j2ee/nombreInstancia/jdk/j2sdk1.4.2_26/bin/java, y aplicar los cambios.

- Ejecutar el comando opmnctl reload.

- Reiniciar la instancia desde el Enterprise Manager.

Y podemos seguir respirando tranquilos.