quarkus

quarkus copied to clipboard

The Link java class from JAXRS API contains a JAXB Adapter that inherits of XmlAdapter (from JAXB API).

The Mandrel native build detects the missing dependency and fails with:

Fatal error: com.oracle.graal.pointsto.util.AnalysisError$ParsingError: Error encountered while parsing org.jboss.resteasy.reactive.common.headers.LinkDelegate$Parser.getLink() 
Parsing context:
   at org.jboss.resteasy.reactive.common.headers.LinkDelegate$Parser.getLink(LinkDelegate.java:29)
   at org.jboss.resteasy.reactive.common.headers.LinkDelegate.fromString(LinkDelegate.java:130)
   at org.jboss.resteasy.reactive.common.headers.LinkDelegate.fromString(LinkDelegate.java:15)
   at javax.ws.rs.core.MediaType.valueOf(MediaType.java:172)
   at org.jboss.resteasy.reactive.common.headers.HeaderUtil.getMediaType(HeaderUtil.java:117)
   at org.jboss.resteasy.reactive.common.jaxrs.ResponseImpl.getMediaType(ResponseImpl.java:208)

Fix https://github.com/quarkusio/quarkus/issues/27211

@geoand I'm not sure this is the right solution, but it works. I've also double-checked that it also fails with older versions of Quarkus. But it works without this change using older versions of Mandrel.

Hm... Not sure it's the way to go actually, as I don't really think we always want to add a dependency to the XML API.

That said, I am not sure what else can be done TBH

@geoand @Sgitario It looks fine to me and makes some sense.

As mentioned in https://github.com/quarkusio/quarkus/issues/27211 the reason why this is happening now is the https://github.com/oracle/graal/commit/ce3d101fba368cdb4bd8eebad770e5c59c8aa57a change in GraalVM (22.3+). Previously it would return the enclosing class as the declaring class and after that change it would return the actual declaring class from the interface. That's my thinking anyway. As to why this doesn't show up with a CE dev build, I'm not sure :-/

Looking at the code of javax.ws.rs.core.Link, there does seem to be a dependency on the XML API.

Given that this feature is likely never going to be used, an alternative to this might be to have substitutions that remove javax.ws.rs.core.Link$JaxbLink and javax.ws.rs.core.Link$JaxbLinkAdapter if the XML API is not on the classpath

Given that this feature is likely never going to be used, an alternative to this might be to have substitutions that remove javax.ws.rs.core.Link$JaxbLink and javax.ws.rs.core.Link$JaxbLinkAdapter if the XML API is not on the classpath

Can't say I'm excited about this. If you use this feature, which is part of JAX-RS, it would work in JVM mode and then would fail in native.

I am pretty sure it does not work in JVM mode even now.

But as I said, no one uses it and we don't explicitly test for it

Looking at the code of javax.ws.rs.core.Link, there does seem to be a dependency on the XML API.

Given that this feature is likely never going to be used, an alternative to this might be to have substitutions that remove javax.ws.rs.core.Link$JaxbLink and javax.ws.rs.core.Link$JaxbLinkAdapter if the XML API is not on the classpath

I tried to do this, however it keeps failing because when loading the class to replace, it also loads also de JAXB annotations :/ I'm not sure if I'm doing it right though.

I'll have a look at this tomorrow to see if there is anything else we can do. If not, we'll have to merge this.

FWIW, I came to the same conclusion when it comes to substitutions in https://github.com/quarkusio/quarkus/issues/27232

You mean that no kind of substitution will work?

You mean that no kind of substitution will work?

No, I'm not saying that, as that would be too generic :-) It seems likely, though. In the case of https://github.com/quarkusio/quarkus/issues/27232 the problem was overriden methods declared in an interface type not on the classpath. So as soon as any such method is seen during analysis, the corresponding type will be attempted to get defined at image build time which then fails. So it depends entirely what you substitute. If you substitute a type that has any relation to the inteface type not on the class path you end up with a chicken-egg-kind-of situation. By substituting you need to have the target loaded at build time etc. In this case it might work depending on how HeaderUtil.getMediaType() looks like and how the path to LinkDelegate comes into being.

Understood, thanks!

What's the status of this? It still generates a lot of noise in our CI testing :-(

I haven't had time to look into it further. Hopefully on Monday

OK, thanks!

This almost certainly can be solved alternatively by doing the following:

• Ensuring that javax/ws/rs/core/Link$JaxbAdapter.class and javax/ws/rs/core/Link$JaxbLink.class are removed from the JAX-RS API jar (this is not too difficult to do).
• Modify the bytecode of javax.ws.rs.core.Link to remove Link$JaxbAdapter and Link$JaxbLink from the inner classes.

I would say this alternative is too much work for too little gain, so let's go ahead and merge this.