Since 3.1.2
CloverETL Server may use external engine plugins loaded from specified source. Source is specified by config property "engine.plugins.src"
See details about possibilities of CloverETL configuration in Chapter 16, Configuration
This property must be absolute path to the directory or zip file with additional CloverETL engine plugins. Both directory and zip must contain subdirectory for each plugin. These plugins are not a substitute for plugins packed in WAR. Changes in the directory or the ZIP file apply only when the server is restarted.
Each plugin has its own class-loader which uses parent-first strategy by default. 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 couple of ways how to ged rid of such conflicts:
Remove your conflicting third-party libraries and use libraries on parent classloaders (web-app or app-server classloaders)
Use different class-loading strategy for your plugin.
in the plugin descriptor plugin.xml, set attribute greedyClassLoader="true" in the element "plugin"
it means, that plugin classloader will use self-first strategy
Set inverse class-loading strategy for selected java packages.
In the plugin descriptor plugin.xml, set attribute "excludedPackages" in the element "plugin".
It's comma separated list of package prefixes. E.g. like this: excludedPackages="some.java.package,some.another.package"
In 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.
Of course, 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 convinient debugging it is 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 "Logging" section for details about overriding server log4j configuration.