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.

Note:

In all examples, the "<classloader-parent>" variable can take the values "platform" for the Platform ClassLoader parent and "common" for the Common 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 Apache 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 plug-in must not have Maven dependencies marked in "<scope>provided</scope>" for libraries that are shipping with Automation Orchestrator as the common ClassLoader would not be able to pick them up, resulting in a malfunctioning 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:

  Libraries:
   - 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 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 still uses version 2.0.0 during runtime since the plug-in ClassLoader follows a parent-first strategy and loads the library classes from the "platform" ClassLoader. If the two versions are incompatible, this can cause you plug-in to break.

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>

• 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>"); 
  } 

• 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 a semicolon (;).