Прочитал ли JasperReports метаданные столбцов перед созданием отчетов?

Question

У меня есть несколько JasperReports, изготовленных и очень хорошо работающих на машине Windows. Проблема началась, когда отчеты были установлены для запуска на мэйнфрейме с операционной системой ZOS.

Проблема в том, что когда Джаспер создает отчет, он, кажется, читает метаданные таблицы из базы данных и, основываясь на нем, ожидают, что данные появятся.
Пример: если у меня есть столбец типа varchar (20), то Jasper будет ждать 20 Chars только даже если поле отчета определено как строка.

Этого не происходит в среде Windows, но в мэйнфрейме кодирование символов является EBCDIC, и поэтому в столбце может быть 19 Chars на мэйнфрейме, но при кодировании его возврата к отчету как 23 или 24 символов.

Примечание. Эта проблема возникает только у неанглийских персонажей.

ОБНОВИТЬ
А ConversionBufferFull брошен, когда Джаспер создает отчет, у меня нет полной трассировки, так как я не могу получить доступ к журналу мэйнфреймов. Проблема возникает только с одним столбцом под названием Country_desc, когда значение составляет около 17-20 ChARS, исключение происходит.

Как я уже упоминал, символ на мэйнфрейме - EBCDIC, но когда он прочитал через JDBC, он преобразован в Unicode. Например, в EBCDIC слово будет 17 chars, но при преобразовании его станет 22. По какой -то странной причине Джаспер ожидает 20 только для этой области.

Answer 1

JasperReports сам не управляет преобразованием данных и длиной поля. Это выглядит как проблема с драйвером JDBC.

Шерман Джасперсфт

Answer 2

sun.io.ConversionBufferFullException брошен sun.io символы, кодирующие преобразователи и могут пробиться через java.io Занятия в старых версиях Java. Этот API устарел в течение некоторого времени и больше не используется с Java 6 - java.nio.charset используется вместо этого.

Это ошибка преобразования персонажа в JasperReports, ваш драйвер JDBC или вещи, используемые этими двумя. Я не думаю, что это имеет какое-либо отношение к чтению мета-дат от результатов JDBC, хотя это может быть строки в метадатах, которые неправильно преобразованы.

Трудно поместить вину или придумать обходную работу без трассировки стека.