The Pluggable UI relies heavily on dedicated class loaders. Whereas the code for a normal web application is only loaded via the basic WebappClassLoader provided by the servlet container (for example, Tomcat), this class loader is only used for loading the classes resembling the PluggableUI base with the underlying Application Designer. The respective classes are loaded from the following directories below <RuntimeWebAppsDir>\PluggableUI:

In addition, locations holding common or shared class or jar files are searched by the WebappClassLoader when attempting to resolve references to required classes.

Any code contributed by a plug-in is loaded by a corresponding instance of the PlugInWebappClassLoader from the following directories below <RuntimeWebAppsDir>/PluggableUI:

If resolution fails, the PlugInWebappClassLoader for the current plug-in will delegate class loading to the PlugInWebappClassLoaders for other plug-ins in the order as listed as <requiredPlugin> in the plugin.xml of the current plug-in recursively. Finally, if resolution via required plug-ins fails, the PlugInWebappClassLoader will delegate class loading to the WebappClassLoader.

The following picture illustrates the scenario of the LifeCycleManagement plug-in (representing any other 3rd party plug-in) that depends on the CentraSiteControl plug-in and the PluggableUI base infrastructure.

The AdapterPlugInClassLoader is used by ApplicationDesigner when resolving references to adapter classes found in layout definitions. The AdapterPlugInClassLoader will never load classes itself. Instead, it will ask all known PlugInWebappClassLoaders in an unspecified order whether they can load a required class.

In general, you should avoid having multiple locations contributing the same classes within the graph of locations spanned by the required plug-ins.