Mule community member, author, and consultant Eugene Ciurana recently discussed a technique for extending or modifying the run-time code in Mule without stopping the server, greatly reducing development time for Mule apps.
Eugene dubs the technique “Mule punching.” The term is based on the Ruby programming jargon duck punching, where if duck typing doesn’t work, you punch the duck until it does. This technique takes advantage of the ability to develop components in Mule using Python and call the reload() command to update them in memory before executing.
If the services app doesn’t do what you need, you can punch the mule until it does by changing the methods and attributes of service components and transformers without stopping the server, and even reconfigure the behavior of third-party packages without access to their code… all while the Mule server runs.
This technique works great in Mule ESB 2; however it is even more useful when combined with the hot deployment capabilities available in Mule 3 that allows another mule punch when the configuration is modified.
Read the full article here.
Disclaimer: No mules were injured in the writing of this post.
