<bean id="muleManager" class="org.mule.extras.spring.config.SpringMuleBootstrap"> <property name="configResources" > <list> <value>classpath:mule-config.xml</value> </list> </property> </bean>
Wednesday, August 1, 2007
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:
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.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment