The Issue
Mule ESB provides a built-in mechanism to call a Spring bean. Mule also provides an entry point resolver mechanism to choose the method that should be called on the desired bean. One such method is the property-entry-point-resolver. This means the incoming message includes a property that specifies the method name. It looks like this:
<component doc:name="Complaint DAO">
<property-entry-point-resolver property="daoMethod"/>
<spring-object bean="acmComplaintDao"/>
</component>
This snippet means the incoming message includes a property “daoMethod”; Mule will invoke the acmComplaintDao bean’s method named by this property.
I’ve had three problems with this approach. First, you can only specify the bean to be called, and hope Mule chooses the right method to invoke. Second, Mule is in charge of selecting and providing the method arguments. Suppose the bean has several overloaded methods with the same name? Third, only an incoming message property can be used to specify the method name. This means either the client code invoking the Mule flow must provide the method name (undesirable since it makes that code harder to read), or the flow design must be deformed such that the main flow calls a child flow only in order to provide the method name property.
How I Resolved the Issue
Last week I finally noticed Mule provides access to a bean registry which includes all Spring beans. And I noticed Mule’s expression component allows you to add arbitrary Mule Expression Language to the flow. Putting these two together results in much simpler code. I could replace the above example with something like this:
<expression-component>
app.registry.acmComplaintDao.save(message.payload);
</expression-component>
The “app.registry” is a built-in object provided by the Mule Expression Language.
In my mind this XML snippet is much more clear and easy to read than the previous one. At a glance the reader can see which method of which bean is being called with which arguments. And it fits right into the main flow; no need to setup a separate child flow just to specify the method name.
A nice simple resolution to the issues I had with my earlier approach. And the new code is smaller and easier to read! Good news all around.
Hello There,
Gasping at your brilliance! Thanks a tonne for sharing all that content. Can’t stop reading. Honestly!
User management and provisioning have always been tedious and time-consuming tasks for IT professionals. If you’ve seen any of my blog posts before, you’ll know that there are two things I like: exposés in the form of parentheses and removing tedious manual work. Naturally, this meant I ended up trying to solve user management. One of the first questions I asked when I started addressing this problem was: why hasn’t this been solved yet?
I read multiple articles and watched many videos about how to use this tool – and was still confused! Your instructions were easy to understand and made the process simple.
Thanks,
Pranavi