Authentication interfers with enricher in Mule 3.3 - mule

Question

I'm currently writing a rather simple mule-flow that uses basic authentication
<custom-transformer class="com.org.HttpRequestToMyRequest" name="HttpRequestToMyRequest" doc:name="Java"/>
<flow name="Input_Flow" doc:name="Input_Flow">
<http:inbound-endpoint exchange-pattern="request-response" host="http://12.23.34.45" port="1234" path="/foo">
<mule-ss:http-security-filter realm="mule-realm"/>
</http:inbound-endpoint>
<flow-ref name="Sorting_Flow" doc:name="Sorting flow"/>
</flow>
<sub-flow name="Sorting_Flow" doc:name="Sorting_Flow">
<transformer ref="HttpRequestToMyRequest" doc:name="Transform Http Request to POJO with interesting methods"/>
<enricher target="#[variable:authorized]">
<http:outbound-endpoint exchange-pattern="request-response" host="12.34.45.56" port="1234" path="foo/bar" method="GET" disableTransportTransformer="true"
responseTransformer-refs="ObjectToString" doc:name="Authorization Service"/>
</enricher>
<choice doc:name="Choice">
<when expression="header:INVOCATION:authorized=true">
<processor-chain>
<component class="com.org.MyClass"/>
<transformer ref="MyObjToString"/>
<http:response-builder status="200" contentType="text/xml" doc:name="HTTP Response Builder"/>
</processor-chain>
</when>
<when SOMETHING ELSE>
DO SOMETHING ELSE
</when>
</choice>
</sub-flow>
If I remove the http-security-filter then this flow works as expected and the payload in the MuleMessage is of the type MyRequest returned by the HttpRequestToMyRequest transformer. But once i add the security-filter the enricher changes my payload from the expected type to a byte[]. If i convert the byte[] to a String then it turns out to be the instancename of MyRequest (com.org.MyRequest#15ae9009).
Any help or ideas would be appreciated.
Edit
Just to be clear. Here are three flow xml fragments where two behave well and the last one has the strange behaviour i don't understand.
This flow, where I've commented out the security-filter on the inbound endpoint, works as expected and the ClassNameLogger statements prints out, in order, String, MyRequest, MyRequest.
<custom-transformer class="com.org.HttpRequestToMyRequest" name="HttpRequestToMyRequest" doc:name="Java"/>
<custom-transformer class="com.org.ClassNameLogger" name="ClassNameLogger" doc:name="Java"/>
<flow name="Input_Flow" doc:name="Input_Flow">
<http:inbound-endpoint exchange-pattern="request-response" host="http://12.23.34.45" port="1234" path="/foo">
<!-- <mule-ss:http-security-filter realm="mule-realm"/> -->
</http:inbound-endpoint>
<flow-ref name="Sorting_Flow" doc:name="Sorting flow"/>
</flow>
<sub-flow name="Sorting_Flow" doc:name="Sorting_Flow">
<transformer ref="ClassNameLogger" doc:name="Logs The Class Name of MuleMessage payload"/>
<transformer ref="HttpRequestToMyRequest" doc:name="Transform Http Request to POJO with interesting methods"/>
<transformer ref="ClassNameLogger" doc:name="Logs The Class Name of MuleMessage payload"/>
<enricher target="#[variable:authorized]">
<http:outbound-endpoint exchange-pattern="request-response" host="12.34.45.56" port="1234" path="foo/bar" method="GET" disableTransportTransformer="true"
responseTransformer-refs="ObjectToString" doc:name="Authorization Service"/>
</enricher>
<transformer ref="ClassNameLogger" doc:name="Logs The Class Name of MuleMessage payload"/>
<choice doc:name="Choice">
<when expression="header:INVOCATION:authorized=true">
<processor-chain>
<component class="com.org.MyClass"/>
<transformer ref="MyObjToString"/>
<http:response-builder status="200" contentType="text/xml" doc:name="HTTP Response Builder"/>
</processor-chain>
</when>
<when SOMETHING ELSE>
DO SOMETHING ELSE
</when>
</choice>
</sub-flow>
This flow, where I've commented out the enricher, works as expected, aside from the fact that it doesn't enter the choise since the variable set by the enricher is not defined. The ClassNameLogger statements prints out, in order, String, MyRequest, MyRequest.
<custom-transformer class="com.org.HttpRequestToMyRequest" name="HttpRequestToMyRequest" doc:name="Java"/>
<custom-transformer class="com.org.ClassNameLogger" name="ClassNameLogger" doc:name="Java"/>
<flow name="Input_Flow" doc:name="Input_Flow">
<http:inbound-endpoint exchange-pattern="request-response" host="http://12.23.34.45" port="1234" path="/foo">
<mule-ss:http-security-filter realm="mule-realm"/>
</http:inbound-endpoint>
<flow-ref name="Sorting_Flow" doc:name="Sorting flow"/>
</flow>
<sub-flow name="Sorting_Flow" doc:name="Sorting_Flow">
<transformer ref="ClassNameLogger" doc:name="Logs The Class Name of MuleMessage payload"/>
<transformer ref="HttpRequestToMyRequest" doc:name="Transform Http Request to POJO with interesting methods"/>
<transformer ref="ClassNameLogger" doc:name="Logs The Class Name of MuleMessage payload"/>
<!-- <enricher target="#[variable:authorized]">
<http:outbound-endpoint exchange-pattern="request-response" host="12.34.45.56" port="1234" path="foo/bar" method="GET" disableTransportTransformer="true"
responseTransformer-refs="ObjectToString" doc:name="Authorization Service"/>
</enricher> -->
<transformer ref="ClassNameLogger" doc:name="Logs The Class Name of MuleMessage payload"/>
<choice doc:name="Choice">
<when expression="header:INVOCATION:authorized=true">
<processor-chain>
<component class="com.org.MyClass"/>
<transformer ref="MyObjToString"/>
<http:response-builder status="200" contentType="text/xml" doc:name="HTTP Response Builder"/>
</processor-chain>
</when>
<when SOMETHING ELSE>
DO SOMETHING ELSE
</when>
</choice>
</sub-flow>
This flow, where I have both the enricher and the security-filter in place, doesn't work as expected and the ClassNameLogger statements prints out, in order, String, MyRequest, byte[].
<custom-transformer class="com.org.HttpRequestToMyRequest" name="HttpRequestToMyRequest" doc:name="Java"/>
<custom-transformer class="com.org.ClassNameLogger" name="ClassNameLogger" doc:name="Java"/>
<flow name="Input_Flow" doc:name="Input_Flow">
<http:inbound-endpoint exchange-pattern="request-response" host="http://12.23.34.45" port="1234" path="/foo">
<mule-ss:http-security-filter realm="mule-realm"/>
</http:inbound-endpoint>
<flow-ref name="Sorting_Flow" doc:name="Sorting flow"/>
</flow>
<sub-flow name="Sorting_Flow" doc:name="Sorting_Flow">
<transformer ref="ClassNameLogger" doc:name="Logs The Class Name of MuleMessage payload"/>
<transformer ref="HttpRequestToMyRequest" doc:name="Transform Http Request to POJO with interesting methods"/>
<transformer ref="ClassNameLogger" doc:name="Logs The Class Name of MuleMessage payload"/>
<enricher target="#[variable:authorized]">
<http:outbound-endpoint exchange-pattern="request-response" host="12.34.45.56" port="1234" path="foo/bar" method="GET" disableTransportTransformer="true"
responseTransformer-refs="ObjectToString" doc:name="Authorization Service"/>
</enricher>
<transformer ref="ClassNameLogger" doc:name="Logs The Class Name of MuleMessage payload"/>
<choice doc:name="Choice">
<when expression="header:INVOCATION:authorized=true">
<processor-chain>
<component class="com.org.MyClass"/>
<transformer ref="MyObjToString"/>
<http:response-builder status="200" contentType="text/xml" doc:name="HTTP Response Builder"/>
</processor-chain>
</when>
<when SOMETHING ELSE>
DO SOMETHING ELSE
</when>
</choice>
</sub-flow>
Edit 2
The code in the HttpRequestToMyRequest transformer
public class HttpRequestToMyRequest extends AbstractMessageTransformer{
#Override
public Object transformMessage(MuleMessage message, String outputEncoding) throws TransformerException {
if("/foo".equals(message.getInboundProperty("http.request.path")){
return new MyFooRequest();
}
if("/bar".equals(message.getInboundParameter("http.request.path")){
return new MyBarRequest();
}
else return new MyEmptyRequest();
}
}
Edit 3
Apparently this was something Mule 3.3 specific. Once I upgraded to 3.4 everything started working as expected.

Answer 1

With Mule 3.4, I notice no difference of payload type with or without the http-security-filter element.
It is either a java.lang.String if the request is an HTTP GET or java.io.InputStream if it is a POST or PUT.
Since you are on 3.3, you are possibly hitting a bug that is gone in 3.4, since I don't have any issue. If that is the case, finding a workaround for the issue on 3.3 would be hairy: upgrading to 3.4 is the path forward.