Implement subsystem variants with semi-isolated class loader

[AFaust]

In some customisation use cases it may be necessary to introduce new libraries or even different versions of libraries already bundled in Alfresco to re-use already existing functionality. This can cause library conflicts due to the single web application class loader that the Alfresco application runs in. The only way to deal with this is by introducing some concept of class loader isolation into Alfresco.

Currently, only Dynamic Extensions provides such a functionality based on OSGi. This addon is not acceptable for use for various reasons:

• introduction of other functionality unrelated to class loader isolation
• extensive inclusion of 3rd-party libraries
• non-standard Alfresco development practices (annotation based wiring)
• incomplete coverage of secondary/tertiary aspects of functionality covered by custom development practices
• non-relevance of hot deploy/undeploy feature in production

Alfresco already provides a base concept of a startable/stoppable sub-context of the application: subsystems. This concept uses a separate Spring application context for isolation of Spring beans. If this were to be coupled with using a partially isolated class loader then the primary requirements for including different versions of libraries / new libraries in an isolated scope would be fulfilled. Other aspects concerning registration of components into the global scope should be handled by further enhancements.

The subsystem class loader should

• fallback to default web application class loader if class / resource could not be found in subsystem
• use a classes / lib sub folder in a subsystem instance as root locations for JARs and/or class files
• have class files override classes from JARs, and have classes / resources found in alfresco/extension/subsystem paths override those found in regular alfresco/subsystem paths

[AFaust]

Support for subsystems with their own classloaders is functionallly complete at this point. Unit tests pass and a separate project (not on GitHub) is already making use of that to add various custom JARs, including overrides to some Apache Commons ones. Documentation still to be done...