Weird behaviour with quarkus.bootstrap.effective-model-builder

[Mario Fusco]

Hi all,

We (the Kogito team) are experiencing a weird problem apparently related in some way with that 'quarkus.bootstrap.effective-model-builder' documented here https://quarkus.io/guides/maven-tooling#bootstrap-maven-properties

In particular in this module we have the test failure that I'm pasting at the end of this email. We never realize this problem because our CI runs with that 'quarkus.bootstrap.effective-model-builder' flag and by using it the problem disappears and the test happily passes. My understanding however was that the flag was only necessary for our CI, while it was not needed when running the test locally. However at some point (maybe since we bumped to the newer Quarkus version?) the test started failing also locally without that flag. Actually I had a hard time to figure out what was the difference between CI and my local environment before I found that the only relevant difference was that flag and using it made the test pass also locally.

At the moment I'm trying to figure out the relationship between that flag and the failing test, but I couldn't. According to what's written in the documentation that I linked above, it should be only necessary to overcome the limitation of parsing the raw pom file. This is needed for complex poms, but this doesn't seem to be the case for our module containing the failing test case.

Are you aware of any other side effect of that flag that could indirectly cause that test to pass? Any help or suggestion is very appreciated.

Thanks,

Mario

-----

ERROR [io.qua.ver.htt.run.QuarkusErrorHandler] (executor-thread-0) HTTP Request to /predict failed, error id: 269a044c-59ed-49e7-b15a-a8db29583542-4: org.jboss.resteasy.spi.UnhandledException: java.lang.LinkageError: loader constraint violation: loader io.quarkus.bootstrap.classloading.QuarkusClassLoader @3d2f3dcb (instance of io.quarkus.bootstrap.classloading.QuarkusClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) wants to load interface org.kie.kogito.Application. A different interface with the same name was previously loaded by io.quarkus.bootstrap.classloading.QuarkusClassLoader @5d01b0d8 (instance of io.quarkus.bootstrap.classloading.QuarkusClassLoader, child of io.quarkus.bootstrap.classloading.QuarkusClassLoader @3d2f3dcb io.quarkus.bootstrap.classloading.QuarkusClassLoader).
        at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:105)
        at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:359)
        at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:218)
        at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:519)
        at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:261)
        at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:161)
        at org.jboss.resteasy.core.interception.jaxrs.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:364)
        at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:164)
        at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:247)
        at io.quarkus.resteasy.runtime.standalone.RequestDispatcher.service(RequestDispatcher.java:73)
        at io.quarkus.resteasy.runtime.standalone.VertxRequestHandler.dispatch(VertxRequestHandler.java:151)
        at io.quarkus.resteasy.runtime.standalone.VertxRequestHandler$1.run(VertxRequestHandler.java:91)
        at io.quarkus.vertx.core.runtime.VertxCoreRecorder$14.runWith(VertxCoreRecorder.java:550)
        at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2449)
        at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1478)
        at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
        at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.LinkageError: loader constraint violation: loader io.quarkus.bootstrap.classloading.QuarkusClassLoader @3d2f3dcb (instance of io.quarkus.bootstrap.classloading.QuarkusClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) wants to load interface org.kie.kogito.Application. A different interface with the same name was previously loaded by io.quarkus.bootstrap.classloading.QuarkusClassLoader @5d01b0d8 (instance of io.quarkus.bootstrap.classloading.QuarkusClassLoader, child of io.quarkus.bootstrap.classloading.QuarkusClassLoader @3d2f3dcb io.quarkus.bootstrap.classloading.QuarkusClassLoader).
        at org.kie.kogito.explainability.ExplainabilityService.processRequest(ExplainabilityService.java:39)
        at org.kie.kogito.explainability.QuarkusExplainableResource.predict(QuarkusExplainableResource.java:51)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:170)
        at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:130)
        at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:660)
        at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:524)
        at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$2(ResourceMethodInvoker.java:474)
        at org.jboss.resteasy.core.interception.jaxrs.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:364)
        at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:476)
        at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:434)
        at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:408)
        at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:69)
        at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:492)

[Alexey Loubyansky]

The option is enabling workspace discovery for the whole repo, not just the module the test belongs to.

W/o looking deeper, what could be happening is a module containing that interface was not found in the workspace due to limitations in the default workspace loader resulting in modules of the workspace being in different class loaders leading to this error.

There a couple of known limitations in the default workspace loader: dependencies in profiles and modules configuring parents that are different from those listing them as modules. Both limitations can be found in the Kogito repo, afair.

At the time that option was suggested for the Kogito CI, the CI issues were reproduce locally as well.

I’ll look again whether we could add support for “inconsistent” parent-child-parent case. In the meantime, we don’t have any other workaround, unfortunately.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALO%3D_Z5QTPTbg1K%2B5MVtGcifRb3gZ2ENnVdantqWG8E65vBhJg%40mail.gmail.com.

[Alexey Loubyansky]

With https://github.com/quarkusio/quarkus/pull/26411, you shouldn't need setting quarkus.bootstrap.effective-model-builder anymore for testing (locally or in CI). I actually ran some Kogito tests to make sure. This should make it into 2.11.0.CR1.

The change is fixing the classloading issues only, which is a big deal in itself, of course. However, it's not a complete replacement for the effective-model-builder option, which enables an alternative workspace loading impl.

--

[Mario Fusco]

That's great news, Alexey, thanks a lot.

Mario