How to use GraalVM Script Engine with Wildfly ?

[Ralph Soika]

Hi,

I have written a workflow engine (http://www.imixs.org) which is using the  org.graalvm.js script engine to support the execution of business rules in  javaScript language.

In wildfly 27.0.1-Final-jdk17 this works fine with graalvm 22.3.5. using the following maven dependencies in my web application:

<dependency>
<groupId>org.graalvm.js</groupId>
<artifactId>js</artifactId>
<version>22.3.5</version>
</dependency>
<dependency>
<groupId>org.graalvm.js</groupId>
<artifactId>js-scriptengine</artifactId>
<version>22.3.5</version>
</dependency>


But if I try to upgrade to the latest graalvm script dependencies to 24.1.1, scripts can no longer be executed by wildfly/graalvm

<dependency>
<groupId>org.graalvm.js</groupId>
<artifactId>js-scriptengine</artifactId>
<version>24.1.1</version>
</dependency>
<dependency>
<groupId>org.graalvm.polyglot</groupId>
<artifactId>js</artifactId>
<version>24.1.1</version>
<type>pom</type>
</dependency>


The problematic code in my workflow engine looks like this:

    public Context getContext() {
        // init context the first time?
        if (_context==null) {
            long l=System.currentTimeMillis();
            _context = Context.newBuilder(languageId) //
                .option("engine.WarnInterpreterOnly", "false") //
                .allowAllAccess(true) //
                .build();
            logger.log(Level.INFO, "...init RuleEngine took {0}ms", System.currentTimeMillis()-l);
        }
        return _context;
    }
   
Building and testing the engine with openjdk 17.0.13 is not problem with both GraalVM Versions. But executing the new GraalVM  with Wildfly 27 or the old GrallVM version iwth Wildfly 29 throws exceptions like this  

Caused by: java.lang.InternalError: java.lang.reflect.InvocationTargetException
  at deployment.imixs-office-workflow.war//com.oracle.truffle.runtime.ModulesSupport.loadModulesSupportLibrary(ModulesSupport.java:170)
  at deployment.imixs-office-workflow.war//com.oracle.truffle.runtime.ModulesSupport.<clinit>(ModulesSupport.java:59)
  at deployment.imixs-office-workflow.war//com.oracle.truffle.runtime.hotspot.HotSpotTruffleRuntimeAccess.createRuntime(HotSpotTruffleRuntimeAccess.java:84)
  at deployment.imixs-office-workflow.war//com.oracle.truffle.runtime.hotspot.HotSpotTruffleRuntimeAccess.getRuntime(HotSpotTruffleRuntimeAccess.java:75)
  at deployment.imixs-office-workflow.war//com.oracle.truffle.api.Truffle.createRuntime(Truffle.java:145)
  at deployment.imixs-office-workflow.war//com.oracle.truffle.api.Truffle$1.run(Truffle.java:176)
  at deployment.imixs-office-workflow.war//com.oracle.truffle.api.Truffle$1.run(Truffle.java:174)


I guess this has to do something with the latest changes in GraalVM as described on this page:

https://www.graalvm.org/latest/graalvm-as-a-platform/language-implementation-framework/migration-to-java-modules/

And my hope is, that this can be solved by defining a corresponding module in Wildfly? But my java knowledge ends at this point. I do not know how to define such a module. And I also have no idea if this will help wildfly to execute my code again.

Can anybody help me out here?

Thanks in advance

===
Ralph

[Brian Stansberry]

Hi folks!

Ralph and I had a discussion about this on https://issues.redhat.com/browse/WFLY-20486 -- you can find the cause and possible solution discussed there.

tl;dr; is in WildFly 28 we stopped exposing Java SE's jdk.unsupported JPMS module to deployments because we feel deployment authors should explicitly choose to access it. Deployments that need it can add a dependency on it via a jboss-deployment-structure.xml deployment descriptor, or by using WildFly's global module feature (https://docs.wildfly.org/35/Admin_Guide#global-modules).

Best regards,

Brian