As I wrote before it is quite easy to set up a web service proxy with Mule3. in this example I take it a step further and I describe how you can add WS-Security implementation to it. Although in the end this also is quite easy you have to make the correct configuration choices to get everything to work.

The first thing I had to do in my Mule config was to drop the pattern prefix. This took me a while to discover because I think this isn’t very clear in the documentation. Anyway, after that change it is fairly straight forward.

Here is the Mule config I ended up with:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:cxf="http://www.mulesoft.org/schema/mule/cxf"
      xmlns:spring="http://www.springframework.org/schema/beans"
      xmlns:http="http://www.mulesoft.org/schema/mule/http"
      xsi:schemaLocation="
        http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/3.2/mule.xsd
        http://www.mulesoft.org/schema/mule/cxf http://www.mulesoft.org/schema/mule/cxf/3.2/mule-cxf.xsd
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/3.2/mule-http.xsd">
 
    <flow name="create-client">
        <http:inbound-endpoint address="http://localhost:8080/create-client">
            <cxf:proxy-service/> 
        </http:inbound-endpoint>
        <http:outbound-endpoint address="http://localhost:8081/create-client">
            <cxf:proxy-client>
                <cxf:outInterceptors>
                    <spring:bean class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
                        <spring:constructor-arg>
                            <spring:map>
                                <spring:entry key="action" value="Timestamp Signature" />
                                <spring:entry key="user" value="${signature.user}" />
                                <spring:entry key="signaturePropFile" value="ws-security.properties" />
                                <spring:entry key="passwordCallbackClass" value="nl.redstream.adapter.MyKeystorePasswordCallback"/>
                            </spring:map>
                        </spring:constructor-arg>
                    </spring:bean>
                    <spring:bean class="org.apache.cxf.interceptor.LoggingOutInterceptor" />
                </cxf:outInterceptors>
            </cxf:proxy-client>
        </http:outbound-endpoint>    
    </flow>
    <flow name="get-client-status">
        <http:inbound-endpoint address="http://localhost:8081/get-status">
            <cxf:proxy-service>
                <cxf:inInterceptors>
                    <spring:bean class="org.apache.cxf.interceptor.LoggingInInterceptor" />
                    <spring:bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
                        <spring:constructor-arg>
                            <spring:map>
                                <spring:entry key="action" value="Signature" /> 
                                <spring:entry key="signaturePropFile" value="ws-security.properties" />
                            </spring:map>
                        </spring:constructor-arg>
                    </spring:bean>
                </cxf:inInterceptors>
            </cxf:proxy-service>
        </http:inbound-endpoint>
        <http:outbound-endpoint address="http://localhost:8080/get-status">
            <cxf:proxy-client />
        </http:outbound-endpoint>    
    </flow>
</mule>

As you can see I have added two flows. The first flow is ‘create-client’. I receive the incoming call from my own ‘inside’-application and add a signature and timestamp to it before I forward it to the ‘outside’ service.
The second flow works the other way around: I receive a signed message from the ‘outside’ client app and I need to validate this before I pas the message to my ‘inside’ application. To create the signature I need the password for to make use of my private key in the keystore. To supply this password I simply implemented the PasswordCallbackHandler that returns the corresponding password by looking it up in a property file. For more info about configuring the WS-security with CFX see here and also I found this entry about Apache WSS4J quite handy.
The security property file that is referred to in my Mule config file contains the following:

1
2
3
4

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=JKS
org.apache.ws.security.crypto.merlin.file=/KeyStores/redstreamKeystore.jks
org.apache.ws.security.crypto.merlin.keystore.password=myPassword

For both flows I added the logging interceptor which is quite handy during testing and developing to see what is received and sent out. In the next post I will show how to generate the keystores and configure SoapUI to test the proxy manually.

When you are using a certain version of Mule ESB you are going to run into an existing bug sooner or later. That isn’t really a problem, I would call it inevitable (at least based on my own experience). The big advantage of the open source idea is that you can dive into the source code and see where the problem is caused and fix it ( or at least work around it). I remember the time I was using Oracle Forms Developer to build applications. When you ran into a bug you had to wait until Oracle was ready to fix/patch it (or, of course, convince the client to not want that specific feature in their application).
Although its true you can find all known bugs for Mule in Jira, you still have to discover yourself your application is having a problem with that known issue. I recently implemented a new interface in our application and I started to make use of the CXF transport (until now it was mainly based on JMS and VM). The exception I got when processing a message was

java.io.IOException: Attempted read from closed stream.

The weird thing was, I didn’t get this exception when running my unit tests and it sometimes even worked in my deployed application.
As I said we got this exception when we added the CXF endpoint, although we did it as described in the manual. Well, to make a long story short, it appeared we were running into this issue. In our deployed version we make use of the Mule Notifications. We have extended the default Mule endpoints so they can indicate if a message they are processing should be logged. This logging is done by receiving the Notification and extracting the message from it. Then we log the payload of the MuleMessage as text in our database.
This works great as long the payload of the message isn’t an InputStream! in case of an InputStream the stream is read to make a String of it and since a InputStream can only be read once, the rest of the application cannot read it again (hence the ‘Attempted read from closed stream‘). This behaviour is described in Jira but you can image that it took some time before we realized we were running into this. Especially because the stack trace isn’t of much use in this case since it is pointing to some deep down CXF code that tries to read the input stream.
Next time someone has a similar issue and you are using Notification Handlers you might want to check these out and this way save yourself a lot of time looking for the cause of this issue.

This post is one of the series of posts about issues that occurred when we were using Mule2 in a real life project. As I wrote in my last post we were using CXF to call a webservice with Mule. After the issues we ran into as described in that article, we ended up with the folowing issue. The generated classes that are used for the XML to Java mapping has to be serializable. This is possible by using a binding file when generating the classes with Maven as described in the documentation here.
However, I haven’t been able to do this in my situation. And according to this post I am not the only one. So to keep the project moving I decided to make use of Metro JAX-WS instead of CXF, since this CXF thing had cost us enough of our precious time. With the Metro implementation we had it running in no time without any unexpected issues.

This post is one of the series of posts about issues that occurred when we were using Mule2 in a real life project. One of the things we had to do with Mule is communicating with a web service. This seemed not to difficult for a tool like Mule that is just build for interaction with other systems. This turned out to be different. We decided to use the CXF transport that comes standard with Mule. However, the web server we were calling was only able to ‘speak’ via HTTP1.0 and therefor didn’t understand ‘chunking’. That led to the following error:
java.net.HttpRetryException: cannot retry due to server authentication, in streaming mode
After lot of googling and searching I found this post that gave us an idea how to solve the problem. We decided to generate CFX client classes and create a Java client for our web service call. That Java class is then configured as a component in Mule. The Java class contains the HTTPConduit code as is stated in the post I mentioned. This got it to work. Afterwards I found another post that solves this same issue but in another way. I haven’t tried it but it looks nice because you don’t have to write any code, only some xml in the Mule config.
But the best solution would be if the supplied ‘cxf.xml’ config file is picked up by Mule in version 2.2.1 so you can arrange it there as it should be working (see some posts here and here about this issue).