Skip jms_replyTo and jms_type headers in DefaultJmsHeaderMapper to support Oracle Advanced Queuing (Oracle AQ) JMS provider [INT-1229]

[spring-operator]

Seva Lo opened INT-1229 and commented

JMS messages coming from a durable, message-driven subscription to an Oracle AQ's topic "do not support" jms_replyTo and jms_type headers. oracle.jms.AQjmsAdtMessage.getJMSReplyTo() and oracle.jms.AQjmsAdtMessage.getJMSType() methods simply throw out an oracle.jms.AQjmsException: JMS-102: Feature not supported. So DefaultJmsHeaderMapper.toHeaders(javax.jms.Message) throws that too when trying to extract the headers.

Workaround: create a custom JmsHeaderMapper implementation and set it to the channel adapter.

To support that nicer we could catch and ignore those exceptions in DefaultJmsHeaderMapper.toHeaders(javax.jms.Message) for Oracle AQ or allow for more flexible (ConfigurableJmsHeaderMapper something?) configuration (perhaps passing the list of JMS API headers we are interested in) without subclassing.

---

Affects: 1.0.4, 2.0 M5

[spring-operator]

Seva Lo commented

Mule and Camel have fixed that: http://www.mulesoft.org/jira/browse/MULE-489 https://issues.apache.org/activemq/browse/CAMEL-2909

[spring-operator]

Oleg Zhurakousky commented

Perhaps something like this could work

<int-jms:inbound-channel-adapter ...> 
    <int-jms:header-filter header-names="jms_replyTo, jms_type"/>
</int-jms:inbound-channel-adapter>

We already have Header Filters as an opposite to Header Enrichers for SI messages. Adding it to JMS adapter/gateways would make it consistent. Thoughts?

[spring-operator]

Mark Fisher commented

I will add the catch-and-ignore behavior first. In fact, we are already catching and ignoring (logging only) on the fromHeaders side, so this seems like the right approach for consistency's sake anyways.

As far as the \, I like the general idea. I think we should consider 2 things: 1) how can we avoid a bias toward negative (filter) or positive (enricher) connotations 2) how can we accomplish this in a generic way - at least in terms of configuration - so that it's a consistent option for adapters (e.g. HTTP also "maps" headers)

For #1, we might want to include something like the exclude and include filters for component-scanning (but sub-elements of sub-elements might be excessive), eg.:

<int-jms:inbound-channel-adapter ...> 
    <int-jms:header-mapper include="jms_*" exclude="jms_replyTo, jms_type"/>
</int-jms:inbound-channel-adapter>

For #2, I guess this issue would be related to #5219. Perhaps we should create a new issue for "generic header-mapping" and then add links to this one and 1214 from that.

[spring-operator]

Mark Fisher commented

I've resolved this issue (those errors are no longer fatal, and no other property <-> header mapping will be bypassed either).

The discussion about include/exclude filters, etc. should be applied to a newly created issue specifically for that enhancement request: #5252

[spring-operator]

Mark Fisher commented

M6 released