[3.5. M4] Separate MULE_HOME and MULE_BASE

Summary

Some users and the Mule Studio team have requested the ability to split the contents of the MULE_HOME directory in two:

• A read-only static part containing the artefacts that can be safely shared across apps. This would be called MULE_HOME
• A dynamic part containing the artefacts that are exclusive to each app. This would be called MULE_BASE

#Contents

MULE_HOME

Directories:

• bin
• data-mapper
• docs
• examples
• lib
• plugins
• src

MULE_BASE

Directories:

• apps
• conf
• domains
• logs
• lib/usr

Configuration

The path for each of these folders will be specified through system properties MULE_HOME and MULE_BASE. Notice that currently Mule startup scripts take the MULE_HOME property and propagate it to the JVM as mule.home. The same pattern will apply to the MULE_BASE which will be propagated as mule.base.

If mule.base is not specified then it will be defaulted to mule.home

Risks & Impact

This is a high risk & impact feature given that we need to change the initialization of many components and make sure that we don't try to look for an artifact in mule.home when it actually belongs to mule.base and vice-versa.

• Need to check how this affects DataMapper
• Not sure about having lib/usr relative to mule_home, because there is no way to shared libraries across all the different mule instances. On the other side, if we put lib/usr on the mule_base then every mule instance will share the same libraries and there is no way to override them.

Identified changes to be made

• Need a central way of obtaining MuleHome and MuleBase paths. This new component needs to be used in every single place that does System.getProperty('mule.home')
• MMC agent: MuleSLAServiceImpl:62 - Should monitor apps directory instead?
• ClusterCoreExtension:210: getTicketFile() needs to look for the working directory instead of the mule home
• ClusterTicketFileLoader: idem ClusterCoreExtension
• MuleApplicationClassLoader: major changes
• Launcher scripts need to be adapted
• Wrapper conf files need to be adapter
• JarUtils needs to be changed
• Migration guide: mule.home is exposed thorough MEL which means migration guide needs to discuss this issue so that apps can be adapted and MuleBase needs to be exposed as well
• ASR & CloudHub: we need to discuss with them how this change affects them
• Studio: They'll need to change their deployer so that they can start mule with the new system properties