[Quarkus 3.0.0.Alpha6] IllegalAnnotationsException Two classes have the same XML type name thrown at build time by quarkus-jaxb

[jamesnetherton]

Something must have changed in Quarkus JAXB because all of the CXF SOAP tests fail with similar Two classes have the same XML type issues like this:

java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
        [error]: Build step io.quarkus.jaxb.deployment.JaxbProcessor#setupJaxbContextConfig threw an exception: java.lang.IllegalStateException: Failed to configure JAXB context
        at io.quarkus.jaxb.deployment.JaxbProcessor.validateContext(JaxbProcessor.java:392)
        at io.quarkus.jaxb.deployment.JaxbProcessor.setupJaxbContextConfig(JaxbProcessor.java:317)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:909)
        at io.quarkus.builder.BuildContext.run(BuildContext.java:282)
        at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
        at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2449)
        at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1478)
        at java.base/java.lang.Thread.run(Thread.java:833)
        at org.jboss.threads.JBossThread.run(JBossThread.java:501)
Caused by: org.glassfish.jaxb.runtime.v2.runtime.IllegalAnnotationsException: 47 counts of IllegalAnnotationExceptions
Two classes have the same XML type name "{http://www.w3.org/2000/09/xmldsig#}ObjectType". Use @XmlType.name and @XmlType.namespace to assign different names to them.
        this problem is related to the following location:
                at org.apache.cxf.ws.security.sts.provider.model.xmldsig.ObjectType
        this problem is related to the following location:
                at org.apache.xml.security.binding.xmldsig.ObjectType
                at public jakarta.xml.bind.JAXBElement org.apache.xml.security.binding.xmldsig.ObjectFactory.createObject(org.apache.xml.security.binding.xmldsig.ObjectType)
                at org.apache.xml.security.binding.xmldsig.ObjectFactory
                at protected java.util.List org.apache.xml.security.binding.xmldsig.TransformType.content
                at org.apache.xml.security.binding.xmldsig.TransformType
                at protected java.util.List org.apache.xml.security.binding.xmlenc.TransformsType.transform
                at org.apache.xml.security.binding.xmlenc.TransformsType
                at public org.apache.xml.security.binding.xmlenc.TransformsType org.apache.xml.security.binding.xmlenc.ObjectFactory.createTransformsType()
                at org.apache.xml.security.binding.xmlenc.ObjectFactory

[ppalaga]

It looks like CXF 4 does not depend on santuario:xmlsec anymore. So quarkus-cxf should also stop depending on Qverse xmlsec. This is surely reproducible also in Qverse CXF.

[ppalaga]

Blocked by quarkiverse/quarkus-cxf#730

[ppalaga]

It looks like CXF 4 does not depend on santuario:xmlsec anymore. So quarkus-cxf should also stop depending on Qverse xmlsec.

No, this is not true. The santuario:xmlsec dependecy is still there, although now it is transitive.

[jamesnetherton]

Just a heads up - in order to upgrade to Quarkus 3.0.0.Alpha5, I had to disable the cxf-soap test bits in c8a4adb.

[ppalaga]

There is a proper fix in Quarkus main branch that did not make it to 3.0.0.Alpha5: quarkusio/quarkus#31666

With Quarkus 3.0.0.Alpha5 this issue can be worked around by putting quarkus.jaxb.validate-jaxb-context=false into application.properties. Let me prepare a PR.