Month: April 2015

Reading Time: 13 minutes

Howdy! This is the last post of the Mule 3.7 series Be sure to check out the other posts in the series:

• A sneak peek into Mule 3.7’s deepest internals »
• One to Contain them All: Unifying the Mule Registry in 3.7 ».

IMPORTANT: If you haven’t read the previous posts in this series, do so now. This will be very difficult to follow otherwise. This post carries the same warning as the first one: it’s mainly intended for developers coding their own custom Mule components. If you’re the kind of person who codes their own components or finds it tasteful to leverage the low-level Mule APIs and internals, then you should definitively read this series of posts. On the other hand, if you’re the kind of user which just simply uses Mule out-of-the-box, and the Anypoint Studio palette gives you all you need, then you probably won’t be as excited about this long read, but it’s recommended anyway; it’s always good to know your tools.

Quick recap of Mule 3.7 posts

So what we learned in the previous posts:

• Mule has a registry that acts as an object container which is decoupled from the actual technology used to fuel it (in our case, the Spring framework)
• That registry is composable and objects are split across two different registries, which leads to inconsistencies and prevents a solid dependency injection mechanism
• Objects in that registry have a lifecycle, which Mule doesn’t apply in a consistent manner

We also discussed how, in Mule 3.7, we’re tackling these issues by unifying all of Mule’s managed objects into one single and unique registry (Spring). The only missing piece after doing that is to rely no longer on the object container to fire the lifecycle phases anymore, which is what this post is about.

The Magic bucket

Before continuing, we need to ask ourselves what’s the relationship between the Mule Registry and the lifecycle. Put in the words of Mule’s founder and creator Ross Mason: “The registry is a ‘magic bucket’ which ensures that all the objects it contains are in the same lifecycle state”. 

So the registry is not only for registering and locating sensible Mule components, but it’s also to ensure that they are all in a consistent lifecycle state, which ultimately is a requisite for them to be able to interact.

If we consider the registry as this “magic bucket” which makes all components transition together, then yes, registries are still responsible for firing those phases on the objects they own. But how to apply those phased once fired is a separate concern. Otherwise, there’s no way to guarantee that the lifecycle will be applied in a uniform and consistent way, regardless of the Registry implementation (SimpleRegistry will behave differently from a SpringRegistry which in turn will be different from a hypothetical GuiceRegistry).

In this way, the Registry interface continues to extend the Lifecycle one, but lifecycle will only be applied once:

• All objects are instantiated
• All objects have been fully injected
• All post-processors have been executed
• A LifecycleManager instance is available to make this transitions. No manual invocation of lifecycle methods at a registry level

Notice that this is very different from what happens on Mule 3.6.x and before, in which:

• The TransientRegistry eagerly calls the initialise phase on which ever object is registered on it
• Spring invokes the initialise phase on every object as soon as it instantiates it, which in some cases can lead to a wrong initialisation order

Initialisation order

Per the discussion in the point above, the correct initialisation order was not being respected by either the TransientRegistry nor the Spring one. Now that initialisation only fires once all objects are injected, the order being respected becomes more relevant.

The initialisation order:

• ObjectStoreManager
• ExpressionEvaluator
• ExpressionEnricher
• ExpressionLanguageExtension
• ExpressionLanguage
• Config
• Connector
• Agent
• Model
• FlowConstruct
• Initialisable

Notice that a new interface has been added: Config. That is a new marker interface that is to be implemented by configs of new connector-ish modules such as the new HTTP connector introduced in 3.6. For now, it’s just an empty interface, but we reserve the right to grow it.

GOTCHA: You might be wondering what happens if a given object implements more than one of those interfaces. There’s logic present to ensure that the same object is not initialised twice.

The Tree of Life (a.k.a. the dependency tree)

The initialisation order described above is good, but not enough in all cases. What happens if a user creates and registers a custom ObjectStoreManager implementation which depends on another registered component, which implements the ExpressionLanguage interface? If this custom ObjectStoreManager tries to access that ExpressionLanguage during the initialisation phase, then it will probably end up in an exception since the latter has not yet been initialised.

All these changes enable us to not only start in a type based order, but also apply a second level of ordering based on dependencies. Before we go down to the practical example, let’s see another theoretical one… Suppose the following tree of dependencies:

Once Mule decides it’s time for object ‘h’ to be initialised, then the initialisation order will be: a, b, c, d, e, f, g, h

Now for the practical example, let’s see how the custom ObjectStoreManager described above would look like:

In this example, the javax.inject.Inject annotation is used to hint Mule into the dependency between these two objects. This will of course work only as long as the dependency is expressed through a Spring bean definition or by the use of JSR-330 annotations such as @Inject. Otherwise, Mule won’t have the necessary information to build a “tree of life”.

GOTCHA 2: The SimpleRegistry implementation that we talked about in the first post does not support trees of life. But that’s fine, because as it was stated, that registry implementation is for testing only.

Injecting external objects

At this point, we have already discussed fixes and improvements that fulfill all issues and wishes listed on the first post of this series. But let’s close this with a new goodie, shall we?

So far we’ve discussed how we can now use dependency injection to wire objects in the registry together. But wouldn’t it be cool is we could also inject dependencies into objects that are not necessarily registered? For example, suppose you are building a custom component which uses the command design pattern. And suppose that you have a command which requires the MuleContext, the ObjectStoreManager, and the QueueManager while also carrying some custom state which prevents you from making that instance reusable (as it’s often the case with the command pattern). Such a command object could look like this:

Because you can potentially need one instance of each of those commands per MuleEvent your component receives, it makes no sense to register each instance just for the sake of dependency injection. However, it would be really neat to be able to fulfil those @Inject statements. Well, it turns out you now can:

Starting with 3.7, there will be a new API in Mule called Injector which, not surprisingly, is capable of injecting dependencies into any JSR-330 annotated object. The fun thing is that injected instances do not go into the registry just because of it.

End of the Mule 3.7 series

Well, that’s it, that’s the end of the Mule 3.7 series. I hope you’re excited about these improvements! As always, please do send your feedback. It really helps us know how things look, and it’s your chance to influence the product greatly!

Thank you for reading!

---

 

Reading Time: 13 minutes

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. Hopefully by the time 3.7 is out, you’ll already be familiar with all the new goodies at your disposal.

The discussion about to start is going to be highly technical, it’s mainly intended for developers coding their own custom Mule components. If you’re the kind of person who codes their own components or finds it tasteful to leverage the low level Mule APIs and internals, then you should definitively read this series of posts. On the other hand, if you’re the kind of user which just simply uses Mule out-of-the-box and the Anypoint Studio palette gives you all you need, then you probably won’t be as excited about this long read, but it’s recommended anyway; it’s always good to know your tools.

A little bit of Mule Anatomy

The MuleContext contains the concept of an object registry. The mule registry is basically a set of key-value pairs used to gain access to relevant mule components, such as connectors, factories, object stores, managers (such as the QueueManager), etc. This is usually known as an Object Container.

• Registries in Mule have a number of attributes:
  They are composable via a RegistryBroker which allows N registries to be added and used.
• The registry implementation is decoupled via a Registry interface. This is so to achieve two goals:
• To allow the core mule to not depend on a third party container such as Spring or Guice (although the
  Spring based registry is the only implementation currently used)
• Allowing users running in embedded mode to plug their own object container.

As a result, when a MuleContext is created, it creates a registry broker with two registries;

i) An instance of TransientRegistry, which is a very basic implementation of the Registry contract
ii) On top of that, the spring-config module also adds a SpringRegistry, which is another implementation of Registry which relies on Spring.

The TransientRegistry contains:

• All the objects declared in a registry-bootstrap.properties file
• Any objects created and registry manually via muleContext.getRegistry().registerXX(), which usually happens in CoreExtension and Agent instances

The Spring Registry contains:

• Every component that was created through an XML config (connectors, configs, flows, message processors, etc).

Spring is then used to host most of the registry objects, including every component which is created from reading an application’s XML configuration (since Spring is used to parse the XML). The TransientRegistry is given priority over every other registry. When an object is requested from the main registry, it searches all registries until a match is found. Because the TransientRegistry goes first, its objects will always have priority.

Interoperability and dependency injection

Because the objects live in two separate registries, then some issues arise:

• Dependency Injection between registries is out of the question. If an object in registry A depends on an object X from registry B, there’s no way to perform that injection (registries start in order)
• Objects in the TransientRegistry cannot access the ones in other registries. For example, the QueueManager lives in the TransientRegistry. That means that when it’s initialised it cannot access the main mule configuration, because such configuration is set through XML and thus lives in the Spring registry, which is started later.
• Overrides are inconsistent. For example, the Cluster extension replaces the default QueueManager and ObjectStore instances by cluster aware versions. Because the TransientRegistry has priority, those are only replaced there. That works fine when doing a manual lookup, but if a component uses Spring dependency injection to get a QueueManager, it will get the local version instead.

The bottom line is that there’s a functional dependency between the TransientRegistry and the SpringRegistry, due to the fact that:

• The Spring registry contains the SimpleRegistryBootstrap
• The Spring registry contains the MuleContext
• Because the Spring registry starts flows, connectors, batch jobs and other components that depend on objects started through the registry bootstrap, we can’t start the spring registry before the TransientRegistry.

These issues prevents us from:

• Have a solid IoC mechanism
• Have a consistent lifecycle across registries

Bringing a Mule to life

Finally but definitely not least, the probably most serious issue with the current registry implementation is how it manages lifecycle. Although this is the most severe problem, I saved it for last because it’s greatly influenced by all the other problems.

The registry has an additional responsibility aside from the ones already described, which Ross Mason described as follows when he first came out with the concept: “The registry is a magic bucket which ensures that all objects are in the same lifecycle state”.

The lifecycle is comprised by 4 phases:

1. Initialise
2. Start
3. Stop
4. Dispose

This is conceptually fine, but the implementation has a lot of problems. The lifecycle is not implemented as something that leverages the registry to make sure that all the important components are transitioned harmoniously. Instead, each registry is in charge of portions of that lifecycle, while some others are handled separately. This leads to inconsistent behaviour:

• The transient registry performs the initialise() operation whenever an object is registered. This means that if the object depends on some other which hasn’t still been registered, it won’t find it (I’m not talking about dependency injection here, this doesn’t work even with a 90’s like lookup)
• The SpringRegistry on the other hand, automatically executes the initialise phase when the bean is instantiated, which means that the initialising object might depend on other objects which are not yet instantiated. This only happens with objects that mule registers on its own, if the user registers a spring bean, lifecycle is not applied to it.
• The SpringRegistry also shows a similar behaviour towards the dispose phase.
• Because the functionality is part of the registry instead of leveraging it, each new registry can potentially have a different behaviour.

Make the Change!

So if you made it this far through all the boring technical definitions and silly mule images, it’s time to actually see what will be different in Mule 3.7!

• Registry unification: In runtime there will be one and only one registry by default: The Spring one. This will make it possible to have a consistent IoC mechanism. You’ll still be able to add your custom registries but that mechanism is deprecated as of this version. Manually added registries will not participate in dependency injection.
• Support for JSR-330 annotations: You custom components will now be able request dependency injection by the use of the @Inject annotation!
• Registry and Lifecycle are now separated: Although the lifecycle mechanism heavily relies on the registry, these are now two separate concepts, handled by separate components.

All the changes above, made it easy to fix all of the lifecycle bugs we had.

TMI!

Ok, this is way too much information for one single post. Please read the next post on this series where we talk about the internals of how this was implemented and migrations considerations when the time comes to adopt Mule 3.7.

Thank you!