Upgrading from JAXB 4.0.1 to 4.0.2 throws ClassNotFoundException

[mnriem]

Caused by: java.lang.ClassNotFoundException: org.graalvm.nativeimage.hosted.Feature
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
... 30 more

[lukasj]

Nothing jaxb code related in the stack trace.

[mnriem]

@lukasj Just to clarify in case it was misunderstood.

Literally the ONLY thing I changed in the application is the following:

I was using:

<dependency>
  <groupId>org.glassfish.jaxb</groupId>
  <artifactId>jaxb-runtime</artifactId>
  <version>4.0.1</version>
</dependency>

And I changed it to:

<dependency>
  <groupId>org.glassfish.jaxb</groupId>
  <artifactId>jaxb-runtime</artifactId>
  <version>4.0.2</version>
</dependency>

And the application throws this exception.

So what do you suggest I do here?

[lukasj]

mvn dependency:tree comparision can be good start and perhaps can lead to finding real cause eventually

[arjantijms]

Thanks for the suggestion @lukasj

I did what you proposed and found the artefact that causes the issue. It's jaxb-runtime, version 4.0.2.

[lukasj]

Also note that I do not know what your app is, how/if it manages classloading, on which JDK and how exactly it is expected to run, during which operation does the exception appear, so whatever I say is just a blind guess - at least till steps to reproduce are provided. Anyway, one obvious workaround is to add graal-sdk to the classpath or modulepath, another is to lower versions of jaxb-runtime dependencies

[mnriem]

After analyzing this myself this stems from JAXB upgrading a dependency. There was NOTHING in the application code that caused the issue. To make it work I had to exclude the angus-activation that was updated.

For folks hitting this issue I changed my dependency to be:

       <dependency>
            <groupId>org.glassfish.jaxb</groupId>
            <artifactId>jaxb-runtime</artifactId>
            <version>4.0.2</version>
            <scope>compile</scope>
            <exclusions>
                <exclusion>
                    <groupId>org.eclipse.angus</groupId>
                    <artifactId>angus-activation</artifactId>
                </exclusion>
            </exclusions>
       </dependency>

[lukasj]

The question on how to reproduce the issue with standalone reproducer remains unanswered

[arjantijms]

@lukasj maybe this one is a problem?

https://github.com/eclipse-ee4j/angus-activation/blob/92299568693522c92709fdca9068358556603539/activation-registry/src/main/java/org/eclipse/angus/activation/nativeimage/AngusActivationFeature.java#L14

Seemingly this class is being picked up by a non-Graal JVM too, and then it obviously all comes down.

[lukasj]

@arjantijms WHY is that class being picked up, by who and when? It is not - or should not be - reachable by any other VM just by itself; unless there is some sort of eager loading in place - if there is, it should not be difficult to provide details.

[arjantijms]

@lukasj After some investigation I managed to obtain some more details.

It concerns Piranha Web Profile, which can be found here: https://github.com/piranhacloud/piranha/tree/current/dist/webprofile

The issue occurs when annotation scanning takes place, which looks at all classes in the class loader. That's why it picks up that class.

So:

WHY - Annotation scanning looks at all classes
Who - Piranha Web Profile, probably some annotationscan module
When - When deploying an application

Reproducer:

Checkout https://github.com/manorrock/persian (https://github.com/manorrock/persian.git)
Revert the exclusion in the POM file
Build using mvn clean install -DskipTests (or don't skip tests and see failure right away)
Run using mvn piranha:run

[lukasj]

missing parts of the stacktrace which clearly identify the WHO part of the problem - shouldn't this been part of the initial report?:

        at cloud.piranha.resource.impl.DefaultResourceManagerClassLoader.loadClass(DefaultResourceManagerClassLoader.java:127)
...
        at cloud.piranha.extension.annotationscan.AnnotationScanInitializer.loadClass(AnnotationScanInitializer.java:130)
        at cloud.piranha.extension.annotationscan.AnnotationScanInitializer.lambda$onStartup$2(AnnotationScanInitializer.java:113)
...
        at cloud.piranha.extension.annotationscan.AnnotationScanInitializer.onStartup(AnnotationScanInitializer.java:115)
        at cloud.piranha.core.impl.DefaultWebApplication.initializeInitializers(DefaultWebApplication.java:1002)
        at cloud.piranha.core.impl.DefaultWebApplication.initialize(DefaultWebApplication.java:931)
        at cloud.piranha.dist.webprofile.WebProfilePiranha.run(WebProfilePiranha.java:243)
        at java.base/java.lang.Thread.run(Thread.java:833)

to me this looks like a problem in how missing annotations are handled in Piranha Cloud.

Consider following case:

• add provided dependency on jakarta.xml.ws:jakarta.xml.ws-api:4.0.0 to the persian webapp and add following service there:

@WebServiceProvider
public class Sample implements Provider<Source> {
    @Override
    public Source invoke(Source request) {
        return null;
    }
}

• build and deploy the application

=> all one can see is following in the output and application seems to run fine:

INFO: WELD-000119: Not generating any bean definitions from com.manorrock.persian.rest.Sample because of underlying class loading error: Type Unable to load class: com.manorrock.persian.rest.Sample not found.  If this is unexpected, enable DEBUG logging to see the full error.

or following case:

• add @WebServiceRef private Object svc; field to the RestApplicationBean class in the app
• build and deploy the application

=> application seems to run fine (there's nothing in the log)

• change the type of the field from Object to jakarta.xml.ws.Service
• build and deploy the application

=> log shows following and application startup fails

WARNING: Initializer cloud.piranha.extension.weld.WeldInitializer failing onStartup
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type RestApplicationBean with qualifiers @Default
  at injection point [UnbackedAnnotatedField] @Inject private com.manorrock.persian.rest.RestResource.application
  at com.manorrock.persian.rest.RestResource.application(RestResource.java:0)
WELD-001474: Class com.manorrock.persian.rest.RestApplicationBean is on the classpath, but was ignored because a class it references was not found: Unable to load class: jakarta.xml.ws.Service.

        at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:367)
...

If piranha is able to handle missing @WebServiceRef/@WebServiceProvider annotations properly, why it is not able to handle other - eventually missing - ones the same way?

[mnriem]

@lukasj Thank you for these details. This will help a LOT!