ClassLoaders

Automation Orchestrator plug-ins are loaded dynamically in the back end during runtime. All Java classes in your plug-in have a ClassLoader and a ClassLoader parent.

Your plug-in can have one of two parent options.

Common parent (recommended)
The parent ClassLoader of your plug-in is the common ClassLoader of Tomcat. Having this ClassLoader as a parent means your plug-in is isolated from the Automation Orchestrator platform classes and you can have dependencies that are independent from it. This also means that your plug-in is bigger in size because you must package all dependencies with your plug-in.
The following JAR files, which correspond to Maven libraries, are provided by this ClassLoader. The version of the JAR files depends on your Automation Orchestrator product version:
```
- com.vmware.o11n.o11n-sdkapi: vRO plug-in SDK API. Interfaces defined by vRO with plug-ins
- org.slf4j:slf4j-api, org.apache.logging.log4j:log4j-api, org.apache.logging.log4j:log4j-core, org.apache.logging.apache.log4j:log4j-slf4j-impl - Common logging API shared between all vRO plugins and vRO platform
- samltoken - Interfaces defined for SSO communication
```
Platform parent (legacy)
The parent ClassLoader of your plug-in is the ClassLoader of the Automation Orchestrator platform. For backward-compatibility reasons this is the default ClassLoader parent. This means that all dependencies which can be provided from the platform are provided to your plug-in.
For example, your use case scenario might require you to depend on a library called com.foo:Bar which is marked as using version 1.0.0 but the Automation Orchestrator instance you depend on already uses this library with the newer version 2.0.0. This means that the "platform" ClassLoader has already loaded the classes for version 2.0.0 of the "Bar" library. Even though your plug-in depends on version 1.0.0 and has packaged it in its .dar file, the plug-in will still use version 2.0.0 during runtime since the plug-in ClassLoader follows a parent-first strategy and will load the library classes from the "platform" ClassLoader. If the two versions are incompatible, this can cause you plug-in to break. On the other hand, by using the "platform" parent, you have a lot of dependencies that are provided by the platform so you do not need to package them with your plug-in. Because of this, the size of your plug-in can be smaller.

You can specify the ClassLoader parent in one of the following ways.

Change the vso.xml if it's not automatically generated.
Open vso.xml and add the following code line as a child of the module element.
```
<classpath parent="<classloader-parent>"</classpath>
```
Automation Orchestrator plug-ins can add additional libraries to their ClassLoader through the vso.xml plug-in descriptor:
```
<classpath parent="<classloader-parent>">
    <file path="path_to_additional_library" />
</classpath>
```
If you develop a plug-in using model-driven, go to your CustomModule and call setClassloaderParent on your plug-in object.
```
public CustomModule() { 
this.plugin = new Plugin(); 
    plugin.setClassloaderParent("<classloader-parent>"); 
} 
```
You can also set additional libraries to be provided to the plug-in by using the following method:
```
plugin.setClasspath(List<String> classpath);
```

If you're using ModuleBuilder to generate the vso.xml file, call the "classpath" method on the ModuleDefinition. For example:

@Override
public void configure() {
    module("<plugin-alias>")
        .displayName("<plugin-name>")
        ...
        .classpath("<classloader-parent>", String[] additionalPaths)
        ...;
    
    ...
}

To resolve use cases for plug-ins that are already released but are affected by incompatibility with the default version of the libraries distributed with the Automation Orchestrator platform, the classpath parent setting can be overridden using a system property:
```
o11n.plugin.<module_name>.classpath.parent=common
```
You can also set additional libraries to be provided to the plug-in using a system property:
```
o11n.plugin.<module_name>.classpath=<path-to-ext-library-1>;<path-to-ext-library-2>;
```
Note: Each individual path to a library must be separated by using a semicolon (";").

In all examples, the "<classloader-parent>" variable can take the values "platform" for the Platform ClassLoader parent and "common" for the Common ClassLoader parent.