la verdad que es muy raro tu error, es muy poco probable que lo vuelvas a ver en bastante tiempo. De cualquier manera no te hagas problema que el error no lo estas produciendo vos y que ademas es casi seguro no tiene consecuencias (DB.isServerObjetcs te va responder lo que debe con error o sin error; salvo que hayas configurado el cliente para que use “objetos en el servidor”; pero no creo que hagas esto; en ese caso isServerObjects te va a retornar N ‘algunas’ veces y de manera casi aleatoria)
La excepción se esta disparando a partir de DB.isServerObjetcs(), un método que es llamado todo el tiempo (cada vez que se ejecuta una sentencia sql contra el servidor…). E.d tu problema, si no fuera lo que explico más adelante, debería ocurrirte a cada rato y tendría el log de errores con miles de ocurrencias del mismo error.
El problema subyacente es que el “chipher” (Secure.s_chipher) (algoritmo para encriptación y desencripción usando por ej, para buscar valores de libertya.properties ) parece no estar “inicializado”…. el tema es que el código justo antes de cada encriptación y desencriptación, lo inicializa!!! (Secure.decrypt(string) y Secure.encrypt(string)
Entonces? Lo único posible que veo (y que si creo que es un bug en Libertya) es que los métodos Secure.decrypt y Secure.encrypt no son accedidos sin control de concurrencia y pueden dar lugar a errores similares a los que comentas (el tema es que los dos métodos usan el mismo objeto chyper, y por ej, lo inicializan de manera distinta). En cualquier caso este error debería ocurrirte de manera un poco aleatoria y no siempre (en el fondo es un error de falta de chequeo de concurrencia). Las probabilidades de ocurra aumentan un poco si por ej estas corriendo el cliente en un sistema multi-nucleo, lo cual es común en estos días (es tu caso?)

Ahora, algo que no viene al tema exactamente, pero Ini creo que debería cachear la propiedad ServerObjects (la propiedad que es accedida todo el tiempo) y no simplemente ir a desencriptar un “N” anteriormente encriptado…. (no se que tan pesado sera el algoritmo de descripción, pero me parece que no son cosas simples).
Para evitar problemas los problemas de concurrencia, se deberían poner locks en los accesos al cipher (se dan solo en Secure.decrypt y secure.encrypt), el tema es que esto puede llevar a cuellos de botellas si hay multiples threads concurrentes (lo cual es el caso cuando se cargan lo MLookups, como muestra la traza de sticuyo). Otro pequeña mejora para evitar esto último (que indirectamente solucionaría el tema de ServerObjecs) es que se Secure precalcule la encriptación de “Y” y “N”; asi por ej, decrypt antes de usar el chipher haria, sin usar ningun lock algo como
if value.equals(YEncriptado) return “Y”
if value.equals(NEcriptado) return “N”

encrpyt por otra parte
if (“Y”.equals (YEncriptado) return YEncriptado
if (“N”.equals (NEncriptado) reutrn NEncriptado

Esto evitaria cuellos de botellas en los locks para strings N e Y que son usadas todo el tiempo.

Otra alternativa es que las strings Y y N nunca se encripten a partir de Ini (y en … no le veo mucho sentido desde el punto de vista de seguridad (uno fácilmente puede darse cuenta cual es valor encriptado para Y y para N)

En lugar de pasarle null, tenés que pasarle un JREmptyDataSource. Fijate en este thread.

Saludos,
Federico

Supongo que ya la encontraste, pero bueno, por las dudas el nombre completo de la clase es
net.sf.jasperreports.engine.JREmptyDataSource
Un ejemplo de clase que la usa es LauchOrdenPago (el informe de la orden de pago)