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.

In this example we will be using this (simple) XML document as source input. The document contains a collection of Customers.

After breaking the XML up into multiple Customer entities, we will insert them into the following database structure:

To split the XML document into multiple Customer entities, we'll use an outbound splitting router like this one:

The xpath evaluator mentioned in the expression-splitter-router excepts both Dom and String objects. This means we can just use plain XML files (no need to create a w3c.dom.Document first. It'll be parsed on-the-fly.

Once the message has been split, we want each Customer to be inserted into a database. The trick here is to use the JDBC transport. We'll need to configure a connector in which
"named queries" can be configured. A "named query" is a PODS (~Plain Old Dml Statement) identified by a key.

In this example, a Map payload is expected from which the values are derived. When using XML, an XPATH expression evaluator seems more appropriate (see final solution).

PS: It might be nice to know that unnamed queries are also supported.

I've introduced the basics, now let's have a look at the complete Mule configuration:

Et voila ... using the above configuration, you will be able to process incoming XML and insert the contents in a database.

Some final notes:

• Use a property-placeholder to configure the database credentials.
• When incoming XML contains namespaces, they could globally be configured using a namespace-manager
• Notice that the jdbc:outbound-endpoint refers to the named query by key
• The named query will be "injected" with a single Customer entity, accessible by the XPATH expression evaluator

• one is Altova generic, so will be reused for each mapping
• one is mapping specific so is the actual part that changes with the mapping (this package name is configurable)

We first jarred the Altova generic code and added it to our Maven repository (Artifactory) so we can include this in our Mule project as dependency. We removed the generated mapping-specific Java code and used the included Ant build script to create the jar file. Here is a screenshot of how it looks in Artifactory:

Now if we want to use Mapforce generated code, we add the following dependency to the pom:

The next step is to add the generated mapping-specific code to the project. We do this by copying the generated mapping specific code to our Mule project (in MapForce you can configure the package name to be used for the generated code so that makes it easier fitting in
with the rest of the code). Here is a screenshot of the code to copy in this case:

Then we created a Transformer class in the Mule project that calls the generated mapping code and returns the result.
Here is an example of a Transformer which uses the generated code:

That's it! Define the transformer as a 'custom-transformer' in your Mule config and your done. You can now create and maintain all your mappings visually with MapForce.
We are now looking into the capabilities that SPL (Spy Programming Language) offer, because it looks like we can generate the Mule Transformer straight from MapForce, that would even boost the producivity more!

The important part is in the 'csv:reader fields' attribute. Here I define the fields that can be expected in my input CSV file. As you can see I apply '?trim' to the fields so additional spaces are removed.
My Mule config file 'smooks-csv-config' that is used for this test can be found here. The important part looks like:

In the transformer the Smooks config file to be used is defined, so in this case I refer to the one I showed in at the beginning of this post. The next step is to create the test class.:

In the file I read the CSV file and put it on the inbound endpoint. The Smooks transformer is then applied to it and the result is passed to the STDIO outbound. So as a result I expect XML output in my console. The CSV file I used for testing looks like:

1888852| 21625|02745011|31|
1888853| 21625|02745011|71|
1888854| 21625|02745011| 3|

And the result in my console contains:

Of course this generated XML is very basic but it can be the base for the next (XSLT) transformation step as I said earlier in this post to create a more advanced XML matching your needs.

• The first thing I had to fix was the fact that the Management Console only works with the Enterprise Edition. Luckily there is a 30 days trial available of the Enterprise Edition here, so I started by downloading that one.
• Next issue was that I wanted to deploy my Mule application as a WAR on a Tomcat instance. To build this WAR I use Maven (of course) so I had to made the Enterprise Edition jars available as dependencies in my repository. Luckily this issue is foreseen by MuleSoft as the Enterprise Edition comes with a script called 'populate_m2_repo' that adds all jars to the local repository. After running this script I was able to build my WAR file packed with the Mule EE jars.
• Next I had to add the Mule Agent to my war. To make this possible I added the agent.jar also to my local Maven repository by running the command:
  

  mvn install:install-file -DgroupId=org.mule.console -DartifactId=mmc-agent -Dversion=2.2.5 -Dpackaging=jar -Dfile=mmc-agent-2.2.5-ea.jar

• With the agent in my repository I just had to add the following dependencies to the pom of my WAR:
  PLAIN TEXT
  XML:

  1. <dependency>
  2.     <groupId>org.mule.console</groupId>
  3.     <artifactId>mmc-agent</artifactId>
  4.     <version>${mule.version}</version>
  5. </dependency>
  6. <dependency>
  7.     <groupId>com.mulesource.muleesb</groupId>
  8.     <artifactId>mule-core-ee</artifactId>
  9.     <version>${mule.version}</version>
  10. </dependency>
  11. <!-- 3rd party libs -->
  12. <dependency>
  13.     <groupId>quartz</groupId>
  14.     <artifactId>quartz</artifactId>
  15.     <version>1.5.2</version>
  16. </dependency>
  17. <dependency>
  18.     <groupId>org.springframework</groupId>
  19.     <artifactId>spring-webmvc</artifactId>
  20.     <version>${spring.version}</version>
  21. </dependency>

  By adding these dependencies my WAR will also contain the Mule Agent that is necessary for the console to monitor my Mule application.

• The next step was deploying the Management Console to the Tomcat server. This is as simple as uploading the WAR to the 'webapps' directory. And after Tomcat has unpacked it and started it you can access it with the following address in your browser 'http://localhost:8080/mmc-server-2.2.5-ea/' (of course only if you didn't change any defaults) and you get the login screen:

After login in with 'admin/admin' you can add your Mule application as a server:

This gives you a lot of information about the machine/processes running that application:

and

Although all this (technical) information is nice to have I think one of the main benefits is found on the 'Services' tab where you can audit, pause, start, etc. your individual service:

For each service you can enable the 'audit' option so each incoming and outgoing message is logged:

Although it is an Early Access release, I haven't found any issue with it, but maybe that's because I only have done some basic routines :-) We will certainly look further into this and I expect the next build of the EA (with more functionality like 'alerts') to become available next week. I'll keep you informed!

As soon as we have set up a test environment (similar to our live situation) and done our first tests we will post the results here so stay tuned!

This is what happens with this configuration: the message is received on the inbound endpoint of the 'start-event-processor' service. The endpoint forwards the mesage to the component 'RoutingComponent'. In this component the next inbound endpoint is determined and added as a property to the XML message. The code for the component looks like:

In the component the method 'routeMessage' is called. In this method I determine what the next step is that has to be performed (in this example "test_vm" is hardcoded as next endpoint but this can easily be made more dynamically). Then the name of that endpoint is added as a property to the message header.
Then the message is passed to my custom-outbound-router. It is a subclass of the 'expression-recipient-list-router' and I made the method 'isMatch' always returning true so no filter has to be used. The code for the router is very simple:

The actual inbound endpoint to which the message is transfered next is determined by making use of my custom evaluator (The creation and use of the custom evaluator is described here. It also explains more about the used xml schema for my message). With this configuration in place it will use the property 'ADDRESS_LIST' in the MessageHeader to obtain the endpoint. Since the dynamic-router in this example always return 'test_vm' the message will be forwarded to that endpoint and be picked up by the 'TEST' service. Here is a test class to test this example:

This class sends an example message to the event-processor. The message will be enriched with a property 'ADDRESS_LIST' in the header that has the value 'vm_test'. So I expect a message on the queue 'test_queue'. If it is not there the test fails, otherwise the router is working correctly.

And example message looks like this:

To get access to the 'Property' elements in the message-header via an 'evaluator expression' I created the following Java class based on the info given here:

I think the code is fairly straightforward. In the method 'evaluate' I receive the payload of the MuleMessage and I check to see if the payload is a JAXBObject of the type Message. If it is a String I assume I receive the XML message as payload and transform the String to the expected JAXB object myself (see this post for more details about this subject).
When I have access to the JAXBObject I simply question the properties of the message for the property name that is supplied with the expression. If a value is found this is returned by the expression.
To make use of this evaluator I 'bootstrapped' it with the Mule application. This can simply be done by adding the file 'registry-bootstrap.properties' to your classpath in the folder 'META-INF/services/org/mule/config' (as explained here). In this file I put:

And that's it. To make use of this evaluator I have in my Mule config:

This will take the property 'ADDR_LIST' out of my Message and use it as outbound Endpoint, but I will explain that in another post.

• an Apache ODE instance (preferably deployed in Tomcat)
• Maven 2.2.0
• JDK 1.6
• Netbeans 6.8,
• Mule CE 2.2.2-SNAPSHOT

Of course, it might work with other version but these are the versions I used.

Step 1: Create a running BPEL process

The first step is to create a running BPEL example. I use the latest version of Netbeans for that and
this post. To make use of the SOA wizards in the new Netbeans you have to enable this as an extension as described here.
To create the BPEL example perform the following steps:

1. Creating a new BPEL module named 'TextModule'
   
2. Add a WSDL to the project

Add a WSDL that describes the web service (remark: I wasn't able to create a document-literal web service with the wizard in Netbeans so I edited the source by hand afterwards). Here is my WSDL.

3. Add a BPEL process to the module, name it 'txtLengthProcess'
   

   This created process is empty so add functionality to it by following the guidelines as in this post. I ended up with the following process diagram:
   
   The mapping in the assignment step looks like this:
   
   I created the necessary variables to assign the values to in the 'receive' and 'reply' step.

4. Create a file 'deploy.xml'
   My file has the following content:
   PLAIN TEXT
   XML:

   1. <?xml version="1.0" encoding="UTF-8"?>
   2. <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03"
   3.     xmlns:pns="http://www.redstream.nl/TxtLengthProcess"
   4.     xmlns:wns="http://www.redstream.nl/TxtLengthService">
   5.  
   6.     <process name="pns:TxtLengthProcess">
   7.         <active>true</active>
   8.         <provide partnerLink="TxtLengthPartnerLink">
   9.             <service name="wns:TxtLengthServiceService" port="TxtLengthServicePort"/>
   10.         </provide>
   11.     </process>
   12. </deploy>

5. Deploy it to the Tomcat instance that is running Apache ODE
   To deploy the process create a directory named 'TxtLengthService' under '/webapps/ode/WEB-INF/processes'. Copy the three files (deploy.xml, TxtLengthProcess.bpel and TxtLengthService.wsdl) to this directory. When your deployment was successful you’ll see the 'TxtLengthService.wsdl' at http://localhost:8080/ode/services/listServices:
   
6. (Optional) you can test the service with SoapUI
   With a successful request-response you will get the following result:
   

If you want more details on how to set up a Apache ODE service have look here. It goes into more detail then I am in this post.

Step 2: Generate Java client for web service to start ODE process

We use Metro for this because we had some bad experiences when using CXF for this. It is described here how to do this in combination with Maven.
I created a new Maven project with this 'pom.xml'.
When the client is generated you can test it with a test class like this:

PLAIN TEXT
JAVA:
1. package nl.redstream.ws.test;
2.  
3. import nl.redstream.txtlengthservice.TxtLengthService;
4. import org.junit.Test;
5.  
6. /**
7. *
8. * @author pascal
9. */
10. public class TestService {
11.  
12.     @Test
13.      public void testIt()
14.     {
15.         TxtLengthService service = new TxtLengthService();
16.  
17.         String value = service.getTxtLengthServiceSOAP11PortHttp().txtLengthOperation("RedStream");
18.  
19.         System.out.println("result = " + value);
20.     }
21. }

Step 3: Create the Mule project

To let Mule call the BPEL process I created a new Maven project that is able to test the call with a Mule client. The project is based on this 'pom.xml'.
The used 'ode-test-config.xml' looks like:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"
3.        xmlns:spring="http://www.springframework.org/schema/beans"
4.        xmlns:test="http://www.mulesource.org/schema/mule/test/2.2"
5.        xmlns:vm="http://www.mulesource.org/schema/mule/vm/2.2"
6.        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
7.        xsi:schemaLocation="
8.        http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
9.        http://www.mulesource.org/schema/mule/test/2.2 http://www.mulesource.org/schema/mule/test/2.2/mule-test.xsd
10.        http://www.mulesource.org/schema/mule/vm/2.2 http://www.mulesource.org/schema/mule/vm/2.2/mule-vm.xsd
11.        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
12.  
13.     <model name="mule-ode">
14.         <service name="start">
15.             <inbound>
16.                 <vm:inbound-endpoint path="msg-in" synchronous="true"/>
17.             </inbound>
18.             <component class="nl.redstream.mule.BpelProcessClient" />
19.         </service>
20.     </model>
21. </mule>

The created component class that handles the call to the SOAP client looks like:

PLAIN TEXT
JAVA:
1. package nl.redstream.mule;
2.  
3. import nl.redstream.txtlengthservice.TxtLengthService;
4.  
5. /**
6. *
7. * @author pascal
8. */
9. public class BpelProcessClient {
10.  
11.     public String callProcess(String request) {
12.         return new TxtLengthService().getTxtLengthServiceSOAP11PortHttp().txtLengthOperation(request);
13.     }
14. }

And the used test class looks like:

PLAIN TEXT
JAVA:
1. package nl.redstream.mule;
2.  
3. import org.junit.Test;
4. import org.mule.api.MuleException;
5. import org.mule.api.MuleMessage;
6. import org.mule.module.client.MuleClient;
7. import org.mule.tck.FunctionalTestCase;
8.  
9. public class BpelProcessClientTest extends FunctionalTestCase {
10.  
11.     private MuleClient client = null;
12.    
13.     protected MuleClient getClient() {
14.         try {
15.             if (client == null) {
16.                 client = new MuleClient();
17.             }
18.         } catch (MuleException e) {
19.             throw new RuntimeException(e);
20.         }
21.         return client;
22.     }
23.  
24.    protected final String getConfigResources() {
25.         return "config/ode-test-config.xml ";
26.     }
27.    
28.     @Test
29.     public void testBpelTest() throws MuleException
30.     {
31.         MuleMessage msg = getClient().send("vm://msg-in", "123456789012345", null);
32.         System.out.println("payload = " + msg.getPayload());
33.     }
34. }

When the test class is executed this results in the following output:

**********************************************************************
* Mule ESB and Integration Platform *
* Version: 2.2.2-SNAPSHOT Build: 15252 *
* MuleSource, Inc. *
* For more information go to http://mule.mulesource.org *
* *
* Server started: 12/17/09 8:34 PM *
* Server ID: 3d3eb71b-eb43-11de-bca6-7b92b51f04e0 *
* JDK: 1.6.0_17 (mixed mode) *
* OS encoding: MacRoman, Mule encoding: UTF-8 *
* OS: Mac OS X (10.6.2, x86_64) *
* Host: macbook-van-pascal-alma.local (192.168.1.204) *
* *
* Agents Running: None *
**********************************************************************
INFO 2009-12-17 20:34:50,730 [main] org.mule.module.client.MuleClient: Using existing MuleContext: org.mule.DefaultMuleContext@1d6b6c55
INFO 2009-12-17 20:34:50,756 [main] org.mule.transport.vm.VMMessageDispatcher: Connected: endpoint.outbound.vm://msg-in
payload = 15
INFO 2009-12-17 20:34:51,784 [main] org.mule.transport.vm.VMConnector: Removing listener on endpointUri: vm://msg-in
INFO 2009-12-17 20:34:51,784 [main] org.mule.transport.vm.VMMessageReceiver: Disconnected: VMMessageReceiver{this=5a56182f, receiverKey=msg-in, endpoint=vm://msg-in}
INFO 2009-12-17 20:34:51,785 [main] org.mule.component.DefaultJavaComponent: Stopping: org.mule.component.DefaultJavaComponent component for: SedaService{start}
INFO 2009-12-17 20:34:51,785 [main] org.mule.model.seda.SedaService: Mule Service start has been stopped successfully
INFO 2009-12-17 20:34:51,787 [main] org.mule.transport.vm.VMConnector: Stopping: VMConnector{this=75d709a5, started=true, initialised=true, name='connector.VM.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[vm], serviceOverrides=null}
INFO 2009-12-17 20:34:51,787 [main] org.mule.transport.vm.VMConnector: Disconnected: VMConnector{this=75d709a5, started=false, initialised=true, name='connector.VM.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=false, supportedProtocols=[vm], serviceOverrides=null}
INFO 2009-12-17 20:34:51,787 [main] org.mule.transport.vm.VMConnector: Stopped: VMConnector{this=75d709a5, started=false, initialised=true, name='connector.VM.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=false, supportedProtocols=[vm], serviceOverrides=null}
INFO 2009-12-17 20:34:51,788 [main] org.mule.util.queue.TransactionalQueueManager: Stopping ResourceManager
INFO 2009-12-17 20:34:51,788 [main] org.mule.util.queue.TransactionalQueueManager: Stopped ResourceManager
INFO 2009-12-17 20:34:51,788 [main] org.mule.transport.vm.VMConnector: Disposing: VMConnector{this=75d709a5, started=false, initialised=true, name='connector.VM.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=false, supportedProtocols=[vm], serviceOverrides=null}
INFO 2009-12-17 20:34:51,788 [main] org.mule.transport.vm.VMMessageDispatcher: Disconnected: VMMessageDispatcher{this=1915470e, endpoint=vm://msg-in, disposed=false}
INFO 2009-12-17 20:34:51,788 [main] org.mule.transport.vm.VMConnector: Disposed: VMConnector{this=75d709a5, started=false, initialised=false, name='connector.VM.0', disposed=true, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=false, supportedProtocols=[vm], serviceOverrides=null}
INFO 2009-12-17 20:34:51,789 [main] org.mule.config.spring.MuleApplicationContext: Closing org.mule.config.spring.MuleApplicationContext@356f144c: display name [org.mule.config.spring.MuleApplicationContext@356f144c]; startup date [Thu Dec 17 20:34:49 CET 2009]; root of context hierarchy
INFO 2009-12-17 20:34:51,789 [main] org.springframework.beans.factory.support.DefaultListableBeanFactory: Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@29abc69: defining beans [customEditorConfigurer,_muleObjectNameProcessor,_mulePropertyPlaceholderProcessor, _muleSimpleRegistryBootstrap,_muleNotificationManager,_muleConfiguration,._muleNotificationManager: notification.1,._muleNotificationManager:notification.2,._muleNotificationManager:notification.3, ._muleNotificationManager:notification.4,._muleNotificationManager:notification.5,._muleNotificationManager: notification.6,._muleNotificationManager:notification.7,._muleNotificationManager:notification.8, ._muleNotificationManager:notification.9,._muleNotificationManager:notification.10,_muleSystemModel, _muleQueueManager,_muleSecurityManager,_muleProperties,_muleEndpointFactory,_muleStreamCloserService, _defaultThreadingProfile,_defaultMessageDispatcherThreadingProfile,_defaultMessageRequesterThreadingProfile, _defaultMessageReceiverThreadingProfile,_defaultServiceThreadingProfile,_defaultRetryPolicyTemplate, mule-ode,start,.start:inbound.11,.start:inbound.11:inbound-endpoint.12,.start:component.13]; root of factory hierarchy
INFO 2009-12-17 20:34:51,995 [main] org.mule.DefaultMuleContext:
**********************************************************************
* Mule shut down normally on: 12/17/09 8:34 PM *
* Server was up for: 0 days, 0 hours, 0 mins, 1.318 sec *
**********************************************************************
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.103 sec

So by finishing this post you should be able to execute a (simple) BPEL process in Apache ODE by using Mule. However, it is not certain we will use Apache ODE like this. I think we would like Intalio|server more because of the handy features/tooling they have added to Apache ODE.

]]> http://blog.redstream.nl/2009/12/18/combining-mule-with-a-bpel-engine/feed/ 0