JasperReports lê os metadados das colunas antes de gerar relatórios?

Question

Eu tenho alguns JasperReports feitos e funcionando muito bem em uma máquina Windows. O problema começou quando os relatórios foram definidos para ser executado em um mainframe com o sistema operacional ZOS.

O problema é: quando Jasper cria o relatório, parece ler os metadados das tabelas do banco de dados e, com base nele, espera que os dados estejam vindos.
Exemplo: se eu tiver uma coluna do tipo Varchar (20), Jasper estará esperando por 20 chars apenas mesmo que o campo de relatório seja definido como string.

Isso não acontece no ambiente do Windows, mas no mainframe o codificação de personagens é ebcdic e, portanto, a coluna pode ter 19 chars no mainframe, mas quando codificada, retornou ao relatório como 23 ou 24 caracteres.

Nota: Esse problema ocorre apenas em caracteres não ingleses.

ATUALIZAR
UMA ConversionBufferFull é jogado quando Jasper está criando o relatório, não tenho o rastro completo, pois não consigo acessar o log mainframe. O problema ocorre com apenas uma coluna chamada country_desc Quando o valor é de 17 a 20 chars, a exceção ocorre.

Como mencionei, o personagem definido no mainframe é o ebcdic, mas quando é lido pelo JDBC, é convertido em unicode. Por exemplo, em Ebcdic, a palavra será 17 chars, mas quando a convertida se tornará 22. Por alguma razão estranha, Jasper espera 20 apenas para este campo.

Answer 1

O JasperReports em si não gerencia a conversão de dados, nem o comprimento do campo. Parece um problema com o driver JDBC.

Sherman Jaspersoft

Answer 2

sun.io.ConversionBufferFullException é jogado por sun.io conversores de codificação de caracteres e podem borbulhar java.io Aulas em versões mais antigas do Java. Esta API está presa por algum tempo e não está mais em uso desde Java 6 - java.nio.charset é usado em vez disso.

É um bug de conversão de caracteres em JasperReports, seu driver JDBC ou coisas usadas por esses dois. Eu não acho que isso tenha nada a ver com a leitura de metados do JDBC ResultSet em si, embora possa ser as cordas nos meta-dados que são convertidos incorretamente.

É difícil colocar a culpa ou pensar em uma subida sem o rastreamento da pilha.