Having fun with Mule

Mule, a very nice open source ESB implementation kept me busy in a not very nice way for 2 days.

In the Mule configuration you can inject properties that are created from another containers, in my case: Spring. You do so with the <container-property>. However, it seemed that these properties were not set on the services that need them. A full day of debugging Mule configuration parsing code gave no results. The properties were correctly loaded from the Spring container but somehow they were not used.

When we found out that another deployment unit of our project did work correctly we started comparing the configurations. It turned out that the configuration was not at all the problem. The problem was a rouge spring bean.

In my setup Mule is started by Spring. From the Spring configuration you simply instantiate Mule with some bootstrap code as follows:

<bean id="muleManager" class="org.mule.extras.spring.config.SpringMuleBootstrap">
  <property name="configResources" >
    <list>
      <value>classpath:mule-config.xml</value>
    </list>
  </property>
</bean>

Unfortunately, one of the other beans that are created by Spring instantiates a MuleClient in its constructor. The new MuleClient starts a Mule core (the MuleManager) if it can not find a running one. I guess you see the problem, a bit later the bootstrap code creates another MuleManager, but by now it is too late and somehow all the container properties get ignored.

Update 2007-08-01: More container property problems: the first transformer gets injected nicely. Somehow another instance is used later on. Not injected with container properties of course.

(Pre-)announcement: transport-smtpin, an embedded e-mail server for Mule

I am proud to (pre-)announce the open source project: transport-smtpin. Transport-smtpin acts as an embedded e-mail SMTP server for the Mule ESB implementation. Under the cover transport-smtpin uses SubEthaSMTP Mail Server (the last freaking java SMTP implementation).

I'll post a download location as soon as I am convinced the implementation is stable (should not take long). Please let me know if you are interested. It will be released under something like the Mozilla Public License Version 1.1.

Update 2007-07-16: This code was sponsored by Uzorg BV.

Update 2007-07-17: A project proposal was made on MuleForge.

Update 2007-8-12: The project has been accepted by MuleForge: mule-transport-smtpin project page. There is no code there yet. It seems to work for me, but not all features are thoroughly tested, nevertheless I'll try to upload the code this week so that more people can play with it.

A bit of history
Transport-smtpin came about when I was searching for a way to directly receive e-mails. In the Dutch health-care a much used standard (mis-)uses e-mail as a request-response protocol: the OZIS standard. The actual messages are in an attachment and are defined by one of many Edifact variants.

In the system I am currently working on, there is actually a person waiting for the answer in such a OZIS request-response cycle. So receiving the responses by polling a POP server would incur an unacceptable overhead.

In an earlier attempt to get e-mail directly we used Apache James. Our mailet installed in James passes received e-mails immediately to our ESB with a Hessian web service. Though writing a mailet is quite easy, this set-up has some serious disadvantages:

• Installing and configuring James for this task is not easy nor straightforward.
• In a cluster, we need to either install one James per cluster node, or devise some way to redirect e-mails to the right cluster node.

In an attempt to get rid of James I stumbled upon SubEthaSMTP Mail Server. SubEthaSMTP is a quite easy to use SMTP server implementation.

As we are using Mule, it would be neat if SubEthaSMTP could be configured as a transport. It took me 3 days (mostly to read Mule documentation), but the result is there: my very first open source project.