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

[WARNING]
[WARNING] Some problems were encountered while building the effective model for nl.redstream.framework:rs-core:jar:2.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-clean-plugin is missing. @
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]

So it appeared we forgot to mention the verion for the clean plugin, so I added the (latest) version to the pom like shown here and went on:

However, after some time we noticed that some of our unit tests started to fail while they were valid and we hadn't touched the code. After some investigation it appeared the problem was caused by the maven-clean-plugin. The version I chose (2.4) is not able to remove complete directories (or at least not with the configuration as we shown above). For some reason, until adding the version, the plugin was using version 2.2. and that does know how to handle my configuration. So I changed the version of the clean-plugin to 2.2 and my tests work like a charm without warnings of Maven.

So although Maven3 does work without a change it does not mean you won't run into issues. But it must be said that we would run into this issue sooner or later without Maven3. So we would suggest to start using Maven3 (or at least give it a try) as it will only improve the quality of your builds (and runs much faster ;-).

• 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!

From the JasperServer log it appeared that the font used in the report could not be found: "JRFontNotFoundException: Font 'Courier New' is not available to the JVM"

Using the following steps I fixed my font-issue (note: I'm a Linux kind-a guy, please translate the following steps to your own environment):

First, we'll need to install the Microsoft TrueType fonts. Excellent reference here: http://corefonts.sourceforge.net. In short, the following steps apply:

• sudo yum install rpmbuild cabextract
• wget http://corefonts.sourceforge.net/msttcorefonts-2.0-1.spec
• rpmbuild -bb msttcorefonts-2.0-1.spec
• Find out where file msttcorefonts-2.0-1.noarch.rpm is located and do rpm -ivh msttcorefonts-2.0-1.noarch.rpm

Now the TrueType fonts are installed (use the fc-list command to display a list of fonts installed), we need to configure JasperServer so they can be used:

• Open a SSH session to the JasperServer machine and goto directory $CATALINA_HOME/shared/classes. I use this directory because its contents is by default on the classpath of Apache Tomcat (and that's exactly where we need the following files) and its non-intrusive with regard to the JasperServer installation;
• Create a file called jasperreports_extension.properties with the following contents (copied from the jasperreports demo directory):

The contents of this file has been copied from the JasperServer documentation. Two things are important: the name of file (JasperServer expects it to be named like this and will automagically load it) and the reference to fonts.xml

• Create a file called fonts.xml with the following contents:

A few remarks:

• Note that the name property should reflect (exactly) the name of the font as used in your JasperReport. I used the name Courier New, because that's what my exception said.
• Properties normal, bold, etcetera, refer to the location of the font. By doing a sudo find / -name *.ttf on our LInux machine, we found out the location of the TTF font.
• When using exotic fonts, the pdfEmbedded property can be used to embed the font into the PDF (actually, the property name itself gave that away). Your PDF will be somewhat larger in size, but the result will be readable.

For a full reference of the possible properties, just check the JavaDoc for SimpleFontFamily. Just remember that each FontFamily gets its own bean.


Now both files are in place, all we need to do now is restart JasperServer (read: Apache Tomcat). Once Tomcat has been restarted, run your report again and the fonts you were previously missing will be there.

We recently had a situation where we preferred a commercial solution over an open source one.
For a specific interface, we had to map a CSV file to an XML file and this transformation should be processed by the Mule ESB. At first we looked at Smooks to tackle this issue, as I described here. It resulted in a workable solution, but as you can read in post, the transformation had to take place in two steps: first from CSV to simple XML format and secondly, a transformation from the simple XML to a more advanced XML schema. For this second transformation we made use of an XSL stylesheet. We created the XSL file used for the transformation by making use of Altova MapForce.
However, MapForce can do a lot more then this simple XML to XML mapping. One of the things it can do is map CSV directly to (advanced) XML. This can't be done with just a XSL translation anymore, but MapForce can generate Java code to perform the transformation at runtime. In this post I will show how you can use MapForce to generate the code. In a next post I will show you how to combine this generated code with the Mule ESB as a transformer.

The CSV file for this example looks like:

firstname|lastname|city|country
Steve|Jobs|Cupertino|USA
Bill|Gates|Washington|USA
Pascal|Alma|Papendrecht|Netherlands

As you can see a pipe-separated file with labels at the first row. When we add it to MapForce as an input source we configure it like:

The XSD to which the CSV file has to be mapped looks like:

In MapForce this target is configured like this:

The mapping in MapForce is quite simple and looks like this:

The output of the mapping can be viewed in MapForce (by pressing the "Output" tab) and looks like this (for this particular input file):

To perform this transformation in a Java environment we'll generate Java code, after setting the package name that is generated by MapForce:

The code that is generated by MapForce looks like this:

As you can see, two packages are generated:

• com.altova

The 'com.altova' package contains 'generic' code that is necessary for each MapForce mapping in Java. It contains global types, functions and so on.

• nl.redstream

The 'nl.redstream' package is the package name we configured. This one contains the code that is specific for our mapping.

Beside these packages a Eclipse project file is generated and a Ant build script. To build this Java code you can run Ant with the following command:

To run the code after you build it you can use the following command:
java nl.redstream.CustomerMappingApplication

You will get a Frame like this:

Unfortunately by using the generated Main classes, the transformation can only be done on the files that where used as input for the mapping in this code. In the next post I will show how to use this generated code and use it as a Transformer in our Mule application.

For a lot more info about the Java generation possiblities of MapForce look here.

When you run this class (and leave it running), you can point your browser to go to 'http://localhost:8181/echo?wsdl' and you receive the wsdl for the web service:

You can now test your tool/ product by using this web service.

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!