GA: DefaultJMSHeaderMapper invalid property names?

[ndw]

Just upgraded to GA release and I'm finding that I now get exceptions from my JMS provider when DefaultJmsHeaderMapper.fromHeaders is called.

It seems that the logic has changed such that SI internal properties are being set on the outgoing messages (eg spring.integration.file.name), and more importantly I am fairly sure these are not valid JMS Property Identifiers ('.' is not allowed according to the jms spec).

Errors are not causing my app to fail and valid properties would be set ok (I think), it's just noise/possibly not what you intended.

My JMS Provider is WS MQ. My application is a simple adaptor polling for files and sending file contents to a JMS Queue.

Stacktrace

WARN 1209-133611.382 task-scheduler-2 org.springframework.integration.jms.DefaultJmsHead erMapper: failed to map Message header 'spring.integration.file.name' to JMS property
javax.jms.MessageFormatException: MQJMS1058: Invalid message property name: spring.integration.file.name
at com.ibm.jms.JMSMessage.newMessageFormatException(J MSMessage.java:4689)
at com.ibm.jms.JMSMessage.setObjectProperty(JMSMessag e.java:5579)
at org.springframework.integration.jms.DefaultJmsHead erMapper.fromHeaders(DefaultJmsHeaderMapper.java:7 1)
at org.springframework.integration.jms.HeaderMappingM essageConverter.toMessage(HeaderMappingMessageConv erter.java:177)
at org.springframework.jms.core.JmsTemplate$5.createM essage(JmsTemplate.java:619)

[JonasPartner]

Thanks for the information. I have created INT-511

[Mark Fisher]

There are a few ways we could address this.

1) provide bi-directional conversion in the JMS header mapper
2) enforce legal java identifiers for all header names throwing IllegalArgumentException anytime a non-legal name is provided
3) continue to log at WARN level for illegal headers but change all internal headers to use underscore delimiters instead of dots

Option #1 would necessitate escaping (in order to handle actual underscores differently than dots-converted-to-underscores) and therefore may become complicated and confusing

Option #2 would be very simple but might be artificially limiting (e.g. prevents someone from providing a URI as the header name)

Option #3 seems to be a decent compromise in my opinion. It's relatively trivial for us to change the internal names, and anyone relying on these should be using the constants for access anyways. If a user wants to provide a non-legal java identifier, they can, but the value would simply be dropped when passing through a JMS adapter.

Please weigh in on these options. I will probably go ahead with #3 for now, since it is fully backwards compatible (assuming users are relying on the constants as they should).

[rganger]

FYI: I'm getting a similar invalid property warning when using JBoss Messaging as the Jms provider. I agree with your solution option #3.

Thanks,
Bob
CUBRC, Inc.

[Mark Fisher]

Yesterday, I committed the changes for option #3, and that will be included within version 1.0.1.

If either of you could possibly test against a snapshot or build from trunk that would be great.

Regards,
Mark

[rganger]

I was having trouble finding the maven snapshots for spring integration. Can you point me to the right repository, and artifact/group/version for your latest spanshot?

Thanks,
Bob
CUBRC, Inc.

[Mark Fisher]

The snapshots are available in the same Maven repository as described here:
http://www.springsource.com/repository/app/faq#q8

You will just need to replace 'release' with 'snapshot'.

Non-final artifacts are browse-able via S3. For example:
http://s3browse.com/explore/reposito...UILD-SNAPSHOT/

[rganger]

I tested version 1.0.1.BUILD-SNAPSHOT and saw the following headers:

springintegration_jms_redelivered
springintegration_id
springintegration_timestamp

JBoss is now happy.

Many thanks...

[Mark Fisher]

Thank you for testing it so quickly!