Howdy! This is the last post of the Mule 3.7 series Be sure to check out the other posts in the series:
IMPORTANT: If you haven’t read the previous posts in this series, do so now. This will be very difficult to follow otherwise.
In this post we’re going to continue the discussion started our last post “A sneak peek into Mule 3.7’s deepest internals” about how Mule’s registry, lifecycle and dependency injection mechanism are being overhauled in Mule 3.7. In this case, we’re going to take a deep dive into how we managed to unify the registries while keeping backwards compatibility and all the implications of such maneuvers.
Mule 3.7 is approaching, and among other things we decided to put a lot of focus on the experience of the guy coding custom components (Devkit based or not). For this, the first 3.7 milestone is incorporating big changes in terms of the how Mule Lifecycle and Dependency Injection are applied.
As I said, these changes are BIG, so for clarity reasons we’ll cover them in a series of post starting with this one.