SROAP02016 ClassNotFoundException for public enums

[scutaru]

When I deploy my application in Wildfly 28.0.1 I get the following type of warnings for all the enums:

2023-07-04 13:37:38,516 WARN [MSC service thread 1-8] [exchangeID=, sessionID=] (io.smallrye.openapi.runtime.io) SROAP02016: Failed to read enumeration values from enum com.example.ErrorSourceEnum method toString with @JsonValue: java.lang.ClassNotFoundException: com.example.ErrorSourceEnum from [Module "io.smallrye.openapi" version 3.3.2 from local module loader @21ba0741 (finder: local module finder @58ce9668 (roots: /opt/jboss/wildfly-28.0.1.Final/modules,/opt/jboss/wildfly-28.0.1.Final/modules/system/layers/base))]

The enum looks like below:

package com.example;

import com.fasterxml.jackson.annotation.JsonValue;

public enum ErrorSourceEnum {
    ISSUER1("ISSUER 1"),

    ISSUER2("ISSUER 2");

    private String value;

    ErrorSourceEnum(String value) {
        this.value = value;
    }

    @Override
    @JsonValue
    public String toString() {
        return value;
    }
}

Any idea what could be wrong ?

[MikeEdgar]

Hi @scutaru , the scanner is attempting to get the value using the method annotated with @JsonValue, but the enum isn't available to the scanner module. Are you using a module-info in your application?

[scutaru]

No, I'm not

[MikeEdgar]

Thanks. Was it working without warnings in an earlier version of Wildfly or is this your first attempt at deploying on Wildfly?

[scutaru]

I'm migrating it from Wildfly 26 to Wildfly 28. But I just checked and the same warnings were displayed in Wildfly 26 too:

2023-07-05 14:29:34,638 WARN [MSC service thread 1-7] [exchangeID=, sessionID=] (io.smallrye.openapi.runtime.io) SROAP02016: Failed to read enumeration values from enum com.example.ErrorSourceEnum method toString with @JsonValue: java.lang.ClassNotFoundException: com.example.ErrorSourceEnum from [Module "io.smallrye.openapi" from local module loader @5a9f4771 (finder: local module finder @282cb7c7 (roots: /opt/jboss/wildfly-26.1.3.Final/modules,/opt/jboss/wildfly-26.1.3.Final/modules/system/layers/base))]

So it's not that urgent anymore, but I'd still like to know how to fix it.

[MikeEdgar]

@pferraro , do you have any insight on what could be the issue? I assume Wildfly modules cannot reflect on the application classes? Is there any work-around?

[pferraro]

@scutaru Do you have a full stack trace? Smallrye is trying to load the enum class from its own module rather than the deployment module, which is certainly wrong. @MikeEdgar Do you know offhand where this might be happening?

[MikeEdgar]

@pferraro , this is the site where the class is loaded:

smallrye-open-api/core/src/main/java/io/smallrye/openapi/runtime/io/schema/SchemaFactory.java

Line 570 in c728c55

Class<?> loadedEnum = Class.forName(className, false, context.getClassLoader());

The class loader that is used would have been set by the client, in this case the integration code in Wildfly. This call to OpenApiProcessor#modelFromAnnotations seems to be the culprit [1].

[1] https://github.com/wildfly/wildfly/blob/c523a7bdea3681f8540e8dd3350ff33d3211b2af/microprofile/openapi-smallrye/src/main/java/org/wildfly/extension/microprofile/openapi/deployment/OpenAPIModelServiceConfigurator.java#L167

[pferraro]

@MikeEdgar Thanks. The problem, as I see it, is that the ClassLoader provided to OpenApiAnnotationScanner serves two different roles: loading AnnotationScanner instances (via AnnotationScannerFactory) and loading application classes.
I can certainly use an aggregating ClassLoader instead - but it would be much cleaner if these could be specified independently, or, even better, allow the platform to bypass the service loading required by AnnotationScannerFactory.

[MikeEdgar]

it would be much cleaner if these could be specified independently, or, even better, allow the platform to bypass the service loading required by AnnotationScannerFactory

Yes, I agree that something needs to change with this. For the second option you gave to bypass the service loading, are you suggesting that the platform would provide pre-constructed AnnotationScanner instances?

[pferraro]

it would be much cleaner if these could be specified independently, or, even better, allow the platform to bypass the service loading required by AnnotationScannerFactory

Yes, I agree that something needs to change with this. For the second option you gave to bypass the service loading, are you suggesting that the platform would provide pre-constructed AnnotationScanner instances?

Either that, or allow it to provide its own AnnotationScannerFactory implementation (assuming this was an interface, or even just a Supplier<Iterable>)

[pferraro]

I opened https://issues.redhat.com/browse/WFLY-18224 and submitted wildfly/wildfly@25dd6bd to fix the issue until given the limitations of the current SPIs.

[scutaru]

@scutaru Do you have a full stack trace? Smallrye is trying to load the enum class from its own module rather than the deployment module, which is certainly wrong. @MikeEdgar Do you know offhand where this might be happening?

Unfortunately that's the only problem that I see in the logs, nothing else.