I've been thinking about configuration of the Mule server and I've come up with some requirements that I would like - 1. To have other configurations methods so that I can easily configure Mule from an XML file, from script such as beanshell/JS, or from some third-party container framework such as Spring or Pico. 2. control over how objects are created, i.e. I want to be able to intercept and override the default method of creating some or all objects in the system. 3. To be able to configure certain objects from JNDI (such as global providers, transformers, global endpoints and such). To a certain degree this is possible but not uniform for all administrative objects. 4. To override the default MuleServer implementation. This was in the original design, but has been overlooked and is currently not cleanly achievable. 5. Sensitive information in the config file should be secure, such as passwords. 6. To have the ability to separate my config file into multiple composite files. This is how these issues could be solved - 1a. Use ConfigurationBuilders to determine how the server should be configured. The builder could be specified as a CL arg with the default one being the MuleXmlConfigurationBuilder. Though you may also have a SpringConfigurationBuilder or JavaScriptConfigurationBuilder. 2a. I propose introducing a central MuleObjectFactory that is used to construct the different types of objects in the system and that can be overridden by custom factory methods. This would giver more control over the creation of all objects in Mule and allow developers to customise as much as they needed. Right now I think this would only apply to the Mule Xml configuration. 3a. A JNDIObjectFactory could be used instead of the default MuleObjectFactory to lookup objects in a JNDI store. 4a. Even the MuleManager would be created via the MuleObjectFactory so it would be easy to override the default implementation. Also, I would provide a default Manager factory implementation that would perform a discovery-style search on the classpath for the UMOManager implementation to use, meaning that the developer need only have their UMOManager implementation on the classpath to use it. 5a. Pass all config files through an expression language such as OGNL (www.ognl.org) so that encrypted passwords and any expressions embedded in the file can be evaluated when the file is loaded and before it is processed. 6a. This really only applies to the Xml Mule config and could be achieved simply by introducing an 'import' element where you can specify a file to import. Though this will impact the mule-configuration.dtd.