Ubuntu 14.04 Trusty Tahr на Asus EEEPC T101MT: проблема с яркостью

Поставил Ubuntu 14.04 Trusty Tahr на свой Asus EEEPC T101MT, и стокнулся со старой доброй проблемой с невозможностью поставить максимальную яркость. Решение - такое же старое, но с небольшой поправкой, связанной с тем, что в репозитории plippo/t101mt нет ветки по версию trusty:

• apt-add-repository plippo/t101mt
• идем в synaptic (можно конечно и через sources.list, но у меня виндовая привычка пользоваться оконными приложениями, что поделаешь), Настройки -> Репозитории -> Другое ПО, находим запись про plippo/t101mt, выделяем, жмем "Изменить", меняем в поле дистрибутив trusty на quantal
• сохраняем, synaptic предложит обновить списки пакетов, обновляем
• после этого устанавливаем пакет eeepc-brightness-workaround, яркость поднимется до максимальной даже без перезагрузки
• теперь яркость максимальна, но не регулируется Fn-комбинациями. Ползунок бегает, а эффекта нет. Идем в /etc/default/grub, меняем значение GRUB_CMDLINE_LINUX_DEFAULT на "quiet splash acpi_backlight=vendor" ("acpi_osi=Linux", как я в свое время делал для Lenovo B460e, ставить не надо). Делаем update-grub, перезагружаемся.

ЗЫ По проблеме с щелчками винчествера также работает старое решение (http://barbitoff.blogspot.ru/2011/04/ubuntu.html).

Netbeans: maven и оффлайн сборка

Включить оффлайн сборку maven-проектов в Netbeans версии 8.0.2, можно, к сожалению, только глобально. Делается это следующим образом: Tools -> Options -> Java -> Maven -> Global Execution Options = --offline.

XPath 1.0: тернарный оператор

Как такового, тернарного оператора в XPath 1.0 нет. Можно реализовать аналогичное поведение, правда, немного замысловатым образом. Следующее выражение даст $stringA, если $cond = true, и $stringB - в противном случае:

concat(substring($stringA, 1 div $cond), substring($stringB, 1 div not($cond)))

WSO2 ESB 4.5.1: использование пространства имен http://ws.apache.org/ns/synapse в XPath-выражениях

Проблема

Есть прокси-сервис, в нем есть property-медиатор, у которого в xpath-выражении в атрибуте expression используется пространство имен "http://ws.apache.org/ns/synapse" с помощью некоторого префикса, который объявлен в этом же property-теге:

<property name="XXXProp" expression="//syn:abc/text()" xmlns:syn="http://ws.apache.org/ns/synapse"/>

Если прокси-сервис отредактировать через веб-консоль шины, объявление префикса пропадает, после чего property-медиатор, естественно, начинает выдавать ошибки из-за неизвестного префикса пространства имен. Если объявление префикса перенести из медиатора выше (хотя даже в сам корневой тег прокси-сервиса), ситуация не меняется.

Решение

Похоже на баг, и вызван он скорее всего тем, что сам конфигурационный xml прокси-сервиса имеет пространство имен по-умолчанию "http://ws.apache.org/ns/synapse". Копаться в исходниках времени не было, поэтому пришлось воспользоваться workaround'ом:

<property name="XXXProp" expression="//*[local-name()='abc']/text()" />

Java: String.split() и пустые значения

Допустим, мы читаем некую строку, в которой значений разделены разделителями-табулциями:

a\tb\tc\t\te

На выходе 

"a\tb\tc\t\te".split("\t")

ожидаем массив из 5 значений, предпоследнее из которых будет пустым. Однако, размер выходного массива будет равен 4, а пустое значение в него не попадет. Выход - немного модифицировать вызов:

"a\tb\tc\t\te".split("\t", -1)

Подробнее: http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#split%28java.lang.String,%20int%29 

ActiveMQ 5.7.0: настройка Dead Letter Queue и числа попыток повторной доставки для отдельной очереди

Задача

Есть некая очередь MyQueue. Для нее нужно настроить (независимо от общих настроек JMS-сервера):

• Отдельную очередь, куда будут складываться недоставленные сообщения из этой очереди (Dead Letter Queue, или сокращённо DLQ), т.к. по-умолчанию в качестве DQL для всех очередей используется очередь с именем ActiveMQ.DLQ
• Число попыток повторной доставки, по истечению которого сообщение будет помещаться в эту самую DLQ

Решение

Настройки выполняются в conf/activemq.xml. Первый шаг - отдельная DQL, настраивается она с помощью блока policyEntry со вложенным deadLetterStrategy:

<destinationPolicy>
<policyMap>
 <policyEntries>
<!-- -->
<policyEntry queue="MyQueue">
 <deadLetterStrategy>
<individualDeadLetterStrategy
 queuePrefix="DLQ." useQueueForQueueMessages="true" />
 </deadLetterStrategy>
</policyEntry>
 </policyEntries>
</policyMap>
</destinationPolicy>

Данная конфигурация указывает использовать в качестве DQL очередь с именем DQL.MyQueue. Помимо префикса, можно также задать постфикс (http://activemq.apache.org/maven/apidocs/org/apache/activemq/broker/region/policy/IndividualDeadLetterStrategy.html). Задать целиком имя очереди, насколько я понял, нельзя. Впрочем, меня устроил и вариант с префиксом.

Теперь про число повторных доставок. Настраиваться она может различными способами (https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_A-MQ/6.0/html/Client_Connectivity_Guide/files/AMQClientConnectRedelivery.html), но server-side способ один - с помощью redeliveryPlugin. Выполняется такая настройка помещением в тот же activemq.xml внутрь блока <broker>:

<plugins>
<redeliveryPlugin>
 <redeliveryPolicyMap>
<redeliveryPolicyMap>
 <redeliveryPolicyEntries>
<!-- a destination specific policy -->
<redeliveryPolicy queue="MyQueue"
 maximumRedeliveries="1" />
 </redeliveryPolicyEntries>
 <!-- the fallback policy for all other destinations -->
 <defaultEntry>
<redeliveryPolicy maximumRedeliveries="10" />
 </defaultEntry>
</redeliveryPolicyMap>
 </redeliveryPolicyMap>
</redeliveryPlugin>
  </plugins>

Особенность заключается в том, что для того, чтобы такая настройка отрабатывала как ожидается, клиент должен при подключении к брокеру указывать jms.redeliveryPolicy.maximumRedeliveries=0.

Apache PdfBox: WARN (XrefTrailerResolver.java:199) Did not found XRef object at specified startxref position 18252

Проблема

При обработке pdf-файла с помощью Apache PdfBox в лог попадает warning:

WARN (XrefTrailerResolver.java:199) Did not found XRef object at specified startxref position 18252

Причина

Если открыть pdf-ку в текстовом редакторе, можно увидеть, что в ней есть блок:

startxref
18252

представляющий из себя ссылку на таблицу перекрестных ссылок ("cross-reference table"). 

Посмотрев в hex-редакторе на адрес 18252 (в шестнадцатеричной системе счисления - это 0x474c) я увидел, что по нему, вместо начала таблицы (ключевого слова "xref") идет окончание ключевого слова endobj, а искомое "xref" идет на 4 байта дальше:

Если поправить ссылку в startxref на корректную (в моем случае - 18256), то warning уходит.