Since 3.1.2
The CloverETL Server can use external engine plugins loaded from a specified source.
The source is specified by engine.plugins.additional.src config property.
See details about the possibilities with CloverETL configuration in Part III, “Configuration”
This property must be the absolute path to the directory or zip file with additional CloverETL engine plugins. Both the directory and zip must contain a subdirectory for each plugin. These plugins are not a substitute for plugins packed in a WAR file. Changes in the directory or the ZIP file apply only when the server is restarted.
Each plugin has its own class-loader that uses a parent-first strategy by default. The parent of plugins' classloaders is web-app classloader (content of [WAR]/WEB-INF/lib). If the plugin uses any third-party libraries, there may be some conflict with libraries on parent-classloaders classpath. These are common exceptions/errors suggesting that there is something wrong with classloading:
java.lang.ClassCastException
java.lang.ClassNotFoundException
java.lang.NoClassDefFoundError
java.lang.LinkageError
There are a couple of ways you can get rid of such conflicts:
Remove your conflicting third-party libraries and use libraries on parent classloaders (web-app or app-server classloaders)
Use a different class-loading strategy for your plugin.
In the plugin descriptor plugin.xml, set attribute greedyClassLoader="true" in the element "plugin"
It means that the plugin classloader will use a self-first strategy
Set an inverse class-loading strategy for selected Java packages.
In the plugin descriptor plugin.xml, set attribute "excludedPackages" in the element "plugin".
It's a comma-separated list of package prefixes – like this, for example: excludedPackages="some.java.package,some.another.package"
In the previous example, all classes from "some.java.package", "some.another.package" and all their sub-packages would be loaded with the inverse loading strategy, then the rest of classes on the plugins classpath.
The suggestions above may be combined. It's not easy to find the best solution for these conflicts and it may depend on the libraries on app-server classpath.
For more convenient debugging, it’s useful to set TRACE log level for related class-loaders.
<logger name="org.jetel.util.classloader.GreedyURLClassLoader"> <level value="trace"/> </logger> <logger name="org.jetel.plugin.PluginClassLoader"> <level value="trace"/> </logger>
See Chapter 11, Logging for details about overriding a server log4j configuration.