Groovy - Generates high number of class loads

[brunovg]

The last implementation of groovy script (StrictSecurityMode ON) is generating a high number of class loads.

[brunovg]

We decided to use groovy component directly from Apache Camel, with a pre validation on flow install.
If validation fails on install, the flow installation is aborted.

[skin27]

We need to test this further, but also extend the valdation to block "evaluate" calls in strict mode.

[brunovg]

The problem
Each time a Groovy script uses dynamic evaluation (GroovyShell.parse(), evaluate(), etc.) inside a Camel flow, the JVM compiles the script string into a new class and registers it in the GroovyClassLoader cache. Since every generated class gets a unique name, the cache never reuses anything — it just keeps growing with every flow execution, leading to metaspace/heap exhaustion over time.

What the client did
On the problematic flow, Erik added a finally block that calls shell.getClassLoader().clearCache() and nulls the shell. This clears the compiled classes after each run, preventing the cache from accumulating. It works, but it's a reactive fix on the client side — if any other script uses eval without this cleanup, the leak comes back.

What's in progress
A PR is open to switch to using Groovy scripts directly from Apache Camel. This means Groovy language support and execution is fully handled by Camel itself, removing the need to maintain that on our side. The only thing we need to own is the pre-evaluation step at flow install time — which is also where we plan to add detection and prevention of eval usage.

What's still pending
The prevention of eval at the backend level is not yet implemented. The exact approach is still being decided, but the pre-evaluation step at flow install is the natural place to enforce it — rejecting any flow whose script contains dynamic evaluation constructs before it ever gets deployed.