SLES и birt: русские буквы в pdf

Проблема

Есть SLES, на нем установлен Tomcat, на котором крутится Birt Report Viewer. На последнем задеплоен отчет, используемый для генерации pdf-файлов, содержащих русский текст. Проблема заключается в том, что русские символы в отчете выгружаются моноширинным шрифтом, причем вне зависимости от того, какой шрифт указан в самом отчете (Calibri, Arial или просто sans-serif).

Решение

Устанавливаем пакет msttcorefonts (http://software.opensuse.org/download.html?project=home%3Acsa7fff%3Aadei&package=msttcorefonts), он распакует в /usr/share/fonts/msttcorefonts некоторый набор TrueType-шрифтов. 

Следующая задача - указать Birt'у на эту папку. Делается это путем правки файла WEB-INF/lib/org.eclipse.birt.runtime_4.5.0.jar/fontsConfig.xml. Этот файл содержит блок <font-paths> с перечнем путей, по которым birt ищет шрифты. Все имеющиеся там записи можно удалить, и добавить одну новую:

<path path="/usr/share/fonts/msttcorefonts" />

Вуаля, шрифты, которые есть в папке /usr/share/fonts/msttcorefonts, можно использовать в отчетах.

ЗЫ Вообще, в файлах fontsConfig.xml, fontsConfig_pdf.xml и fontsConfig_linux.xml есть и другие настройки, которые могут оказаться полезными: например, можно выбрать, какой шрифт будет использоваться при указании семейства "serif", указать fallback-шрифт, используемый, когда для символа невозможно найти глиф в указанном шрифте (<composite-font name="all-fonts"  ... />) и пр.

Birt Report Viewer: логирование

Чтобы получить максимальный уровень логирования для Birt Report Viewer'а, необходимо в его web.xml задать значение параметра BIRT_VIEWER_LOG_LEVEL равным FINEST:

<context-param>
<param-name>BIRT_VIEWER_LOG_LEVEL</param-name>
<param-value>FINEST</param-value>
</context-param>

Логи пишутся в папку log корня развертывания веб-приложения. 

WSO2 ESB 4.9.0: пропадает контент бинарного узла при его создании с помощью ByteArrayInputStream + org.apache.axis2.builder.unknowncontent.InputStreamDataSource

Проблема

Некий кастомный Java-медиатор создает бинарный XML-узел, наполняя его из массива байт byte[], используя ByteArrayInputStream и org.apache.axis2.builder.unknowncontent.InputStreamDataSource:

ByteArrayInputStream stream = new ByteArrayInputStream(myBytes);
DataSource ds = new InputStreamDataSource(stream);
DataHandler dataHandler = new DataHandler(ds);
OMText binaryNode = factory.createOMText(dataHandler, true);

При этом созданный узел ведет себя крайне странно: если попробовать 2 раза подряд залогировать созданный XML, в первый раз он логируется корректно (бинарный узел логируется base64-кодированным), а при повторном логировании оказывается, что бинарный узел уже пуст.

Решение

Особо не разбирался, реализовал создание DataSource напрямую из массива байт:

DataSource ds = new org.apache.axiom.attachments.ByteArrayDataSource(myBytes);

WSO2 ESB 4.9.0: при отправке запроса теряются WS-Addressing заголовки

Проблема

Прокси-сервис устанавливает WS-Addressing заголовки, но при отправке запроса на конечный веб-сервис они теряются, запрос на веб-сервис приходит уже без них.

Решение

Решается проблема установкой соответствующего свойства контекста:

<property name="PRESERVE_WS_ADDRESSING" value="true"/>

WSO2 ESB 4.9.0: ошибка "Name cannot contain any special characters other than hyphen (-) and underscore (_)" при создании Datasource

Проблема

Пытаюсь создать Datasource через веб-консоль WSO2 ESB 4.9.0, при попытке проверки соединения ("Test connection") получаю ошибку:

Name cannot contain any special characters other than hyphen (-) and underscore (_)

При этом имя датасорса не содержит никаких спецсимволов, только строчные латинские буквы.

Причина

Видимо, некорректный regexp для валидации поля "Name", до конца так и не понял, что именно ему не нравится, но знаю точно - если вместо строчных букв использовать заглавные - ошибка не возникает. Названия из строчных букв также иногда прокатывают, но не все (например, если в названии есть буква "s" - то ошибка гарантирована). Нашел похожую багу, заведенную на WSO2 Data Analytics Server: https://wso2.org/jira/browse/DAS-116, там, похоже, проблему поправили, а вот в ESB - нет. 

Spring Tools Suite: ошибка "You need to run build with JDK or have tools.jar on the classpath..." при просмотре pom-ки

Проблема

При открытии в Spring Tools Suite pom-ки проекта вверху отображается ошибка:

You need to run build with JDK or have tools.jar on the classpath...

Причина

STS запущен из-под java из jre, а не JDK.

Решение

Поправить PATH системы таким образом, чтобы java бралась из JDK, а не из JRE. 

PostgreSQL: ERROR: could not open extension control file "/usr/pgsql-9.4/share/extension/uuid-ossp.control": No such file or directory

Проблема

Есть PostgreSQL-сервер на Linux'е. Пытаюсь установить расширение uuid-ossp SQL-запросом:

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

Получаю ошибку:

ERROR:  could not open extension control file "/usr/pgsql-9.4/share/extension/uuid-ossp.control": No such file or directory

Решение

Не установлен пакет postgresql-contrib, необходимо установить его. Например, для deb-системы с apt-ом:

apt-get install postgresql-contrib