Script Task Classloader Clarification

Camunda 7 Topics Discussion & Questions
1

Hi,

I am using the AWS Java SDK in a kind of service task. I have implemented the ‘service task’ as a script task using groovy. I have installed the AWS SDK jar into the Tomcat container lib folder.

When I use the process model in a servlet based web application using the Camunda maven template, all works fine. (I have added the AWS SDK maven dependency into the pom file).

If I now take the exact same bpmn file and deploy it using the cockpit deploy API, I get a runtime exception. In particular, the stacktrace indicates that deep with the AWS SDK it throws a class not found exception.

Hence my question, is there some sort of class loader difference between a process application versus a standalone deployment within the groovy script engine?

regards

Rob

2

Hi Rob,

I haven’t checked this, but this is how I think it works :slight_smile: : The difference with classloading in this case is that with a process application the script is executed in the context of the process application’s classloader (which delegates to the container’s shared classloader). In case of deployment via Cockpit (if not registered with a process application), the process engine’s classloader is used which in case of a shared engine should be the container’s shared classloader.

If that is correct, then I guess that the missing class was present in your process application but was missing in the shared lib folder. If the missing class is part of the AWS SDK jar, then I am puzzled that some classes can be loaded and others cannot.

Cheers,
Thorben

3

Thanks Thorben,

This is precisely my expectation as well. The stacktrace gives me a classdef not found within the AWS library, hence puzzling…I will try to dig deeper…

R

4

Hi Rob,

Happy debugging. To narrow down the problem, you could try setting the engine configuration option enableScriptEngineCaching to false. There were issues in that area in combination with the Groovy scripting engine, see https://app.camunda.com/jira/browse/CAM-3432 (the gist there was that the Groovy scripting engine caches a classloader that may or may not become invalid over time).

Cheers,
Thorben

5

Hi Thorben,

Solved - issue is as follows;

Stacktrace indicates an AWS class cannot be created;

java.lang.NoClassDefFoundError: Could not initialize class com.amazonaws.partitions.PartitionsLoader

On looking at the AWS class source, to instantiate the AWS class requires a Jackson class. Hence I had to install the fasterxml jackson jar files. After installing these jar files, I found they used the Apache http client. hence I had to install the http client jar files.

So the short answer is during a process application build, maven is managing the dependencies behind the scenes. If you are not using maven, then you need to ensure that all the nested dependencies are explicitly accounted for and the jars must be installed in the container library.

regards

Rob

6