Mule Flow-Under The Hood [Part 2]
Introduction
This article is an extension to my previous article.
In the previous post, I explained what lies under the hood of a Mule Flow. Now, in this article I will try to explore the same concept in a different and easy way and to show some hacking tricks.
Spring Bean & Mule 4
There are some changes from Mule 3 to Mule 4 regarding the Spring Bean configurations. I will not delve into this but please feel free to explore them in the official MuleSoft documentation.
For this experiment, let's configure a Java class in a Mule project and register this class to the Spring Framework.
Spring Bean
Below is my simple Spring Bean.
Bean Configuration
Below is the beans.xml where the bean is declared. It’s a simple declaration without any complex initialization logic.
Mule Flow
Below is a simple Mule Flow to invoke my bean. Note that it's invoking the sayHello() method of the bean class.
Deploy
Now, let's deploy the application in Mule Runtime, either standalone or embedded Anypoint Studio Mule runtime.
Note: For some reasons the debugger did not enter into my MyBean class.
Now check the logic of the sayHello() method.
First, let's check what it will print if I search for the testFlow bean in the Spring ApplicationContext.
Next, what the F*** I am doing? Closing the context. What will happen? Any, guess?
Okay, now let's check. Let's deploy and invoke the service.
First Execution
It printed the testFlow bean. It's an Object of class DefaultFlow. After that it closed the Spring Application Context.
Second Execution
Now check what happens in the second execution. The flow is technically dead because we closed the whole Spring Application Context.
Check the error printed and it's more than well expected.
Crazy stuff. Huh!
Conclusion
Well, no one should close the Application Context in a Mule Application. It will kill your whole application. It's just an informative article to explore how to play with the Mule Platform and show that Mule is NOTHING but Spring.
Happy Weekend!
