barbitoff programmer`s blog

Здесь я публикую заметки из программерской жизни: грабли, на которые мне случилось наступить, проблемы, для которых было найдено элегантное (или не очень) решение, а также все, с чем мне пришлось столкнуться и чем хотелось бы поделиться =)
PS Если хотите меня поблагодарить - на странице есть 3 места, чтобы это сделать =)
Показаны сообщения с ярлыком transport headers. Показать все сообщения
Показаны сообщения с ярлыком transport headers. Показать все сообщения

среда, 5 августа 2015 г.

WSO2 ESB и IBM WebSphere MQ: "Имя свойства 'Content-Type' не является верным идентификатором Java(tm)"

Сделал простейший прокси-сервис HTTP-> JMS (в качестве JMS-провайдера используется IBM WebSphere MQ 7.5), при его вызове получаю ошибку в логах:
TID: [0] [ESB] [2015-08-05 13:10:28,219] ERROR {org.apache.axis2.transport.jms.JMSSender} -  Error creating a JMS message from the message context {org.apache.axis2.transport.jms.JMSSender}
com.ibm.msg.client.jms.DetailedMessageFormatException: JMSCC0049: Имя свойства 'Content-Type' не является верным идентификатором Java(tm).
Указанное имя свойства не соответствует разрешенному формату, описанному в спецификации JMS.
Причина в том, что с точки зрения спецификации JMS имя свойства не может содержать символов "-". WSO2 же пытается пробросить в качестве свойства JMS-сообщения пришедший во входящем вызове HTTP-заголовок. Решение:
<property action="remove" name="TRANSPORT_HEADERS" scope="axis2"/>
<property action="set" name="transport.jms.ContentTypeProperty" value="CONTENT_TYPE" scope="axis2"/>
В данном случае тип контента будет записан в JMS-свойство "CONTENT_TYPE".

суббота, 9 февраля 2013 г.

WSO2 ESB 4.5.1 + IBM WebSphere MQ 7.0.1.3: ошибка JMSCC0051 при попытке положить сообщения в очередь

Проблема:

Есть прокси сервис, перекладывающий сообщения из одной JMS-очереди в другую JMS-очередь (обе очереди на WebSphere MQ). При попытке положить сообщение в конечную очередь валится исключение:
com.ibm.msg.client.jms.DetailedMessageFormatException: JMSCC0051: The property 'JMS_IBM_PutApplType' should be set using type 'java.lang.Integer', not 'java.lang.String'. JMS_IBM properties may only be set using a specific variable type. Correct application code to use the required variable type when setting this JMS_IBM property.

Решение:

Чистить транспортные заголовки перед отправкой на endpoint:
<property action="remove" name="TRANSPORT_HEADERS" scope="axis2"/> 
Какой именно из транспортных заголовков мешает MQ, я не изучал.


суббота, 8 декабря 2012 г.

WSO2 ESB: UnmappableCharacterException при отправке сообщения sender`ом HttpCoreNIOSender

Проблема:

Есть 2 прокси-сервиса, один - VFS -> JMS, принимающий файлы, обрабатывающий их и сладывающий сформированный SOAP в очередь, и другой - JMS->HTTP, отправляющий это сообщение конечному сервису. В последнем при отправке сообщения sender`ом HttpCoreNIOSender валится исключение:
[2012-12-06 10:20:18,108] ERROR - ClientHandler I/O Error submitting request : Input length = 1
java.nio.charset.UnmappableCharacterException: Input length = 1
        at java.nio.charset.CoderResult.throwException(CoderResult.java:278)
        at org.apache.http.impl.nio.reactor.SessionOutputBufferImpl.writeLine(SessionOutputBufferImpl.java:160)
        at org.apache.http.impl.nio.codecs.AbstractMessageWriter.write(AbstractMessageWriter.java:93)
        at org.apache.synapse.transport.nhttp.LoggingNHttpClientConnection$LoggingNHttpMessageWriter.write(LoggingNHttpC
lientConnection.java:137)
        at org.apache.http.impl.nio.DefaultNHttpClientConnection.submitRequest(DefaultNHttpClientConnection.java:241)
        at org.apache.synapse.transport.nhttp.LoggingNHttpClientConnection.submitRequest(LoggingNHttpClientConnection.ja
va:78)
        at org.apache.synapse.transport.nhttp.ClientHandler.processConnection(ClientHandler.java:256)
        at org.apache.synapse.transport.nhttp.ClientHandler.connected(ClientHandler.java:204)
        at org.apache.http.impl.nio.DefaultClientIOEventDispatch.connected(DefaultClientIOEventDispatch.java:134)
        at org.apache.http.impl.nio.reactor.BaseIOReactor.sessionCreated(BaseIOReactor.java:284)
        at org.apache.http.impl.nio.reactor.AbstractIOReactor.processNewChannels(AbstractIOReactor.java:419)
        at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:286)
        at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104)
        at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:54
2)
        at java.lang.Thread.run(Thread.java:722)

Причина:

Причина оказалась в русских именах файлов. Дело в том, что VFS кладет имя файла и полный путь к нему в транспортные заголовки "FILE_NAME" и "FILE_PATH". Эти заголовки сохраняются при прохождении сообщения через JMS и попадают sender`у. А тот, видимо, не любит не-ASCII-символы в заголовках и валится. В качестве workaround`а можно удалять проблемные заголовки перед отправкой сообщения:
<property action="REMOVE" name="FILE_NAME"
                scope="transport" value=""/>
<property action="REMOVE" name="FILE_PATH"
                scope="transport" value=""/>
, или, если они нужны, скажем, в out sequence, можно перекладывать значения в свойства в области видимости default.

четверг, 22 ноября 2012 г.

WSO2 ESB: доступ к транспортному заголовку из медиатора

Доступ к транспортным заголовкам из медиатора осуществляется немного нетривиально:
public boolean mediate(MessageContext context)
{
org.apache.axis2.context.MessageContext axis2MsgContext;
axis2MsgContext = ((Axis2MessageContext)context).getAxis2MessageContext();
Map transportHeaders = (Map)axis2MsgContext.getProperty(org.apache.axis2.context.MessageContext.TRANSPORT_HEADERS);
System.out.println("FILE_NAME header is:\n\n"+(String)transportHeaders.get("FILE_NAME")+"\n\n");
}
В итоге выведенное в консоли значение будет совпадать с получаемым с помощью лог-медиатора:
<log level="custom">
<property name="FILE_NAME" expression="synapse:get-property('transport','FILE_NAME')"/>
</log>