IllegalAnnotationsException when mixing quarkus-cxf and rest services that uses XML as serialisation format

[rudiger3d]

Hi,

I have a service that both uses quarkus-cxf to call a couple of webservices, as well as a rest client used to call a rest endpoint that happens to use XML as its serialisation format (quarkus 2.X).

When trying to call the rest endpoint I get the following exception:

java.lang.RuntimeException: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 51 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
                at public javax.xml.bind.JAXBElement org.apache.cxf.ws.security.sts.provider.model.xmldsig.ObjectFactory.createObject(org.apache.cxf.ws.security.sts.provider.model.xmldsig.ObjectType)
                at org.apache.cxf.ws.security.sts.provider.model.xmldsig.ObjectFactory
                at protected java.util.List org.apache.cxf.ws.security.sts.provider.model.xmldsig.X509DataType.x509IssuerSerialOrX509SKIOrX509SubjectName
                at org.apache.cxf.ws.security.sts.provider.model.xmldsig.X509DataType
        this problem is related to the following location:
                at org.apache.xml.security.binding.xmldsig.ObjectType
                at public javax.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.SignatureMethodType.content
                at org.apache.xml.security.binding.xmldsig.SignatureMethodType
...

I can understand from this issue that duplicate JAXB classes is to be expected when using CXF.

This isn't strictly a quarkus-cxf issue, as the webservices works as they should, however is there anything I can do on quarkus 2.X other than providing my own JaxbContext bean?

On quarkus 3.X the issue seems to have been fixed by this commit as quarkus began validating the JaxbContext at build time.

[ppalaga]

On quarkus 3.X the issue seems to have been fixed by this commit as quarkus began validating the JaxbContext at build time.

I would not say, that commit "fixes" the issue universally on Quarkus 3.x. You can still hit it at build time. It would be interesting to know whether that's your case.

This isn't strictly a quarkus-cxf issue, as the webservices works as they should, however is there anything I can do on quarkus 2.X other than providing my own JaxbContext bean?

I frankly do not know because I am still rather new to this area. It would be nice know whether a custom context helps.

[rudiger3d]

would not say, that commit "fixes" the issue universally on Quarkus 3.x. You can still hit it at build time. It would be interesting to know whether that's your case.

As I'm still on Quarkus 2.x I am seeing the issue at runtime. The JaxbContext is validated by quarkus-jaxb-subsystem when serialising/deserialising XML. I should emphasize that I'm not seeing the issue on the quarkus-cxf side of my service, i.e. when calling a webservice.

I frankly do not know because I am still rather new to this area. It would be nice know whether a custom context helps.

It does. But so far I'm not as proficient as quarkus in creating a correct JaxbContext that covers several "roots", and I run into issues with the generated XML (again this problem is seen when calling rest-endpoints, not webservices). Thus, if one could avoid any manual tinkering it would be nice :)

So I was just a little puzzled that no other has run into similar problems on quarkus 2.X, but perhaps no one is mixing quarkus-cxf and quarkus-resteasy-(client-)reactive-jaxb.

[ppalaga]

would not say, that commit "fixes" the issue universally on Quarkus 3.x. You can still hit it at build time. It would be interesting to know whether that's your case.

As I'm still on Quarkus 2.x I am seeing the issue at runtime. The JaxbContext is validated by quarkus-jaxb-subsystem when serialising/deserialising XML. I should emphasize that I'm not seeing the issue on the quarkus-cxf side of my service, i.e. when calling a webservice.

Yeah, that's quite possible because CXF sets up its own JAXB contexts, which are IIRC properly isolated per service.

I frankly do not know because I am still rather new to this area. It would be nice know whether a custom context helps.

It does. But so far I'm not as proficient as quarkus in creating a correct JaxbContext that covers several "roots", and I run into issues with the generated XML (again this problem is seen when calling rest-endpoints, not webservices). Thus, if one could avoid any manual tinkering it would be nice :)

I am wondering what should be the proper solution in Quarkus 3.x. In Quarkus 3.x, it is currently possible to exclude individual classes via quarkus.jaxb.exclude-classes : https://quarkus.io/guides/all-config#quarkus-jaxb_quarkus.jaxb.exclude-classes
So you could exclude all CXF stuff and leave only the ones required by your REST client. Would that be flexible enough for you? Would the configuration perhaps be much easier if there was also quarkus.jaxb.include-classes?

[rudiger3d]

quarkus.jaxb.exclude-classes sounds like a promising solution. I haven't yet had a chance to look into Quarkus 3.x so I am a hesitant to say if it is sufficient or if it were easier with quarkus.jaxb.include-classes. But yes - quarkus.jaxb.include-classes might be the easier solution when the set of classes to include is quite a bit smaller than the set to exclude.

It'll probably be a couple of weeks before I will have a chance to look at again, but I wanted to say thanks for the replies so far!

[ppalaga]

@Sgitario I guess we will see this kind of issues more often now that CXF is a part of Quarkus Platform. I am not sure at all what is the right way forward. Do you have any opinion about quarkus.jaxb.include-classes mentioned above?

[Sgitario]

Let me give some context here: the Quarkus JAXB extension will auto-discover the JAXB classes (via annotation, or standard JAXB manifests) and will bind these classes to a JAXBContext instance. We can alter the classes to be bound by using the property quarkus.jaxb.exclude-classes which can be used to exclude individual classes or packages. The Quarkus RESTEasy Reactive JAXB extension will transitively bring the Quarkus JAXB extension, so the marshallers/unmarshallers can inject the above JAXBContext instance.

About the CXF extension, I guess we're speaking of https://github.com/quarkiverse/quarkus-cxf, right?

Now, if the problem here is that this extension transitively brings JAXB classes that are incompatible with each other when bound in the same JAXBContext instance, then I think the way to go is that this extension produces a build item to always exclude these classes:

• The Quarkus CXF will continue working because CXF sets up its own JAXB contexts
• The Quarkus RESTEASY Reactive extension will also continue working because if the class to use is not found in the above JAXBContext instance, it will request a new one.

I would like to understand better the option of adding the property quarkus.jaxb.include-classes. What would you like to do is to disable the auto-discover feature of JAXB classes to only include the ones you set in this property ? If so, I see the additional value of it.

[rudiger3d]

Now, if the problem here is that this extension transitively brings JAXB classes that are incompatible with each other when bound in the same JAXBContext instance, then I think the way to go is that this extension produces a build item to always exclude these classes:

• The Quarkus CXF will continue working because CXF sets up its own JAXB contexts
• The Quarkus RESTEASY Reactive extension will also continue working because if the class to use is not found in the above JAXBContext instance, it will request a new one.

Yes, the problem is that the CXF extension brings in incompatible classes JAXBContext-validation wise. (Validation is done at runtime on quarkus 2.X when calling a "JAXB" endpoint.)

My work-around so far has been to provide my own JAXBContext. This is of course doable, but surprising seen as a consumer of various quarkus extensions.

If quarkus CXF could set up a "clean" global JAXBContext, I as the "consumer" don't really have an opinion about quarkus.jaxb.include-classes or quarkus.jaxb.exclude-classes, because as far as I can tell, both my cxf endpoints and my rest endpoints requiring xml serialisation would just work.