Generated openapi ignores attributes annotated with XmlElement if class is annotated with XmlAccessType.NONE

[troosan]

Describe the bug

@XmlAccessorType(XmlAccessType.NONE) seems to take precedence over @XmlElement
The response of the service itself is correct.

I have created a little dummy project to reproduce the issue: https://github.com/troosan/quarkus-jaxb-openapi-reproducer

the schema generated is not showing any attributes

Expected behavior

the openapi contract shows the attributes annotated with XmlElement

Actual behavior

NONE are shown

How to Reproduce?

1. checkout https://github.com/troosan/quarkus-jaxb-openapi-reproducer
2. browse to http://localhost:8080/q/swagger-ui/#/ and check the generated schemas, no attribute is shown

Output of uname -a or ver

Darwin MacBook-Pro-2.local 22.5.0 Darwin Kernel Version 22.5.0

Output of java -version

openjdk version "17.0.6" 2023-01-17

GraalVM version (if different from Java)

OpenJDK 64-Bit Server VM GraalVM CE 22.3.1 (build 17.0.6+10-jvmci-22.3-b13, mixed mode, sharing)

Quarkus version or git rev

powered by Quarkus 2.16.6.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.1

Additional information

Unfortunately I cannot upgrade to Quarkus 3.x yet as I do not control the entities returned by the service.
those are annotated with javax.xml.bind and not jakarta.xml.bind
it also means I am stuck with jaxb annotations, hence the use of JaxbAnnotationModule

actually, the same issue exists with quarks 3, and using the JakartaXmlBindAnnotationModule

[quarkus-bot]

/cc @EricWittmann (openapi), @MikeEdgar (openapi), @phillip-kruger (openapi)

[troosan]

@MikeEdgar I have given it a try here https://github.com/troosan/quarkus-jaxb-openapi-reproducer/tree/quarkus_3_2
I don't see any difference though.

Any chance this fix will be ported to the minor version used by quarkus 2?

[MikeEdgar]

@troosan , the scanner runs during the build (via quarkus-maven-plugin), so updating the app's dependency won't impact that. You should have better results testing it with that dependency added to the plugin. Once it's released, I'll have to evaluate if 3.4.x of the scanner is compatible with Quarkus 2 (I think it may be) to say if it can be back-ported.

[troosan]

Thanks for the hint. Indeed, checking out Quarkus, changing the dependency and compiling did indeed fix the issue.

[troosan]

while this particular issue is working with the fix delivered in 3.5.0 there are still other issues with the jaxb support.
see smallrye/smallrye-open-api#1510