MessagingException: failed to transform message headers

[Wrangler]

The first message I send to my project occasionally errors with "MessagingException: failed to transform message headers", subsequent messages do not have this error. I am using JMeter to send in the messages to a SI deploy on Weblogic 10.3.6 with SI 2.2.1.

My configuration is as follows:

<int-http:inbound-gateway...

<!--Enrich with the transactionId to use for Audit logging -->
<int:header-enricher id="enrichWithTransactionId"
                         input-channel="ws-rawInboundChannel"
                         output-channel="ws-inboundChannel">
        <int:header name="transactionGuid" expression="headers.id"/>
    </int:header-enricher>

    <!--Add to the SI Message object a header field, payload is untouched-->
    <int:header-enricher id="enrichWithSoapHeader"
                         input-channel="ws-inboundChannel"
                         output-channel="enrichedWithSoapHeaderChannel">
        <int:header name="MySoapHeader" method="parse" ref="jaxb2012RequestParser"/>
    </int:header-enricher>

    public MySoapHeader parse(Message<SoapMessage> siMessage,
        @Header("transactionGuid") String transactionId) {...}

Since headers.id is a java.net.UUID, it has a toString() method to convert. However the first message after a deploy gets this message:

Caused by: org.springframework.integration.MessageHandlingException: org.springframework.expression.spel.SpelEvaluationException: EL1004E:(pos 8): Method call: Method parse(org.springframework.integration.message.GenericMessage,java.util.UUID) cannot be found on com....parser.JAXB2012RequestParser type
	at org.springframework.integration.handler.MethodInvokingMessageProcessor.processMessage(MethodInvokingMessageProcessor.java:76)
	at org.springframework.integration.transformer.HeaderEnricher$MessageProcessingHeaderValueMessageProcessor.processMessage(HeaderEnricher.java:270)
	at org.springframework.integration.transformer.HeaderEnricher.transform(HeaderEnricher.java:113)

If I clone the method into a second method with the second parameter using java.net.UUID, SI will (correctly) complain that both methods (UUID and String) are both candidates for SI to call and they need to be different.

The error "Method call: Method parse(org.springframework.integration.message.Gene ricMessage,java.util.UUID) cannot be found on com.....parser.JAXB2012RequestParser " is not correct, because it works after the first message.

After JMeter sends in the messages, and I rerun the same messages again, they all work.

Any ideas on how to get around this error?

[Gary Russell]

This is related to a recent issue we fixed in 2.2.1 https://jira.springsource.org/browse/INT-2889); I believe we need to synchronize the initial creation of the TypeConverter (that is used to convert the UUID to a String). The recent fix synchronizes the use of the editor, but I can see that the creation of the TypeConverter suffers from a similar problem. However, I believe it's the second message that's failing because the list of available property editors is only partially built when it gets a reference to the shared SimpleTypeConverter.

Until we have a fix, you have a couple of work arounds...

1.

public MySoapHeader parse(Message<SoapMessage> siMessagea,
        @Header("transactionGuid") UUID transactionIdUUID) {
    String transactionId = transactionUUID.toString()
    ...
}

2. Or, since you already have the full message, you really don't need the second parameter...

public MySoapHeader parse(Message<SoapMessage> siMessage) {
    String transactionId = ((UUID) siMessge.getHeaders().get("transactionGuid").toString();
    ...
}

I'll open a JIRA for this problem.

[Wrangler]

Gary,

Thank you for the information so quickly. I changed the code to use option #2, and tested again. Each of the test passed the JMeter assertion. Please post the Jira link when you create it so I can "watch" it.

[Gary Russell]

Great!

https://jira.springsource.org/browse/INT-2922

[Gary Russell]

This issue is now resolved in 2.2.2.RELEASE.

[Wrangler]

This issue is now resolved in 2.2.2.RELEASE.

Awesome, thanks! I will get that version now.