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.

Although we see many advantages in using (free) open source tools or frameworks we keep our eyes open to check whether the chosen open source solution is best for our customer.

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.
Continue reading…

As I promised before here is an example of how to use Smooks in combination with Mule. In this example I transform a CSV file to a plain XML file. This XML file can then be transformed with an XSLT transformation to the desired XML format.
Continue reading…

As I said before we were asked to check out the new Management Console of Mule. In this post I will show the steps I took to get the console up and running and the first results of the evaluation.

• 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.
  Continue reading…

Currently we’re evaluating the Mule Management Console: a new product from MuleSoft that replaces Mule HQ.
We have had a look at Mule HQ before and decided that it was not offering the functionality we were looking for. Apparently we weren’t the only ones with this conclusion because MuleSoft decided to build a new Management Console from scratch. It is now available as an Early Access release and MuleSoft asked us to evaluate it.

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!

Refactoring code is part of daily business for any programmer.

Recently, I’ve discovered http://refactormycode.com/. Haven’t used it yet, but I thought I’d share this gem.

You have the possibility to describe the challenge you’re facing, copy-and-paste any (relevant) code and then … you wait. Brilliant!

A very nice example of involving the community when refactoring your next piece of software.

Recently, Netbeans 6.8 GA was released. Great news … but unfortunately, SOA and UML support has disappeared from the release.

The SOA plugins are no longer available and at the moment there are no plans to bring back this feature set. NetBeans 6.1 and 6.5 were the last releases with full support for SOA functionality.

“Official” reaction from the Netbeans forum:

I know, it’s unfortunate that we don’t have the resources to support every feature we want to.. SOA, UML and Visual Web development are no longer supported, but Java EE 6, PHP support, and many other improvements have been made and more are on the way for next release.

Continue reading…

Redstream is a fresh new company specialized in integration technologies in the most broad sense of the word. The company is started by enthusiastic general specialists with many years of IT experience at your disposal.


Altough we officially start our business on 01-01-2010, we’ve opened our company blog. This blog is one way of communicating with the world. As a start, some old posts have been updated, re-polished and are reposted. Enjoy!

More info? Send an e-mail to info@redstream.nl.