ppalaga commented on issue #8061: URL: https://github.com/apache/camel-quarkus/issues/8061#issuecomment-3716284387
@jerboaa, your PR https://github.com/quarkusio/quarkus/pull/51432 causes hard time for us in Camel Quarkus. Is my understanding correct that the main motivation for your PR was the adaptation of Quarkus to the new GraalVM json metadata format (so far available only in GraalVM master branch) where only full reflection registrations are possible? You are thus deliberately expanding the set of reflection registrations for already released GraalVM versions although it would not yet be needed for those, right? From what I can see, the issues we see here are (at least partly) caused by the fact that the full reflection registration pulls in types which are not available in the class path at all. E.g. `org.springframework.core.io.Resource` (see the error message below) is from an optional dependency `org.springframework:spring-beans` of `org.apache.cxf:cxf-rt-ws-policy`. Our JVM tests pass fine without that dependency. Native tests fail, because `org.apache.cxf.ws.policy.attachment.external.ExternalAttachmentProvider` referencing the Spring `Resource` is pulled in via one of its interfaces. I added some details to the hierarchy registration warning in this branch: https://github.com/ppalaga/quarkus/commits/260106-hierarchy-registration-warning/ The class graph traversal path for `org.springframework.core.io.Resource` is as follows: ``` - org.springframework.core.io.Resource <--------- UNAVAILABLE IN TCCL, source: - JaxbProcessor annotated with @jakarta.xml.bind.annotation.XmlRootElement -> org.apache.camel.model.RoutesDefinition -interface-> org.apache.camel.CamelContextAware -implementor-> org.apache.camel.component.cxf.jaxws.CxfEndpoint -method-return:getBus()-> org.apache.cxf.Bus -implementor-> org.apache.cxf.bus.spring.SpringBus -interface-> org.springframework.context.ApplicationContextAware -implementor-> org.apache.cxf.configuration.spring.ConfigurerImpl -interface-> org.apache.cxf.extension.BusExtension -implementor-> org.apache.cxf.ws.policy.PolicyEngineImpl -method-return:getPolicyProviders()-> java.util.Collection -type-arg-> org.apache.cxf.ws.policy.PolicyProvider -implementor-> org.apache.cxf.ws.policy.attachment.external.ExternalAttachmentProvider -method-return:getLocation()-> org.springframework.core.io.Resource ``` Those interface -> implementor hence and forths do not seem to make much sense. They include lots of classes that have nothing to do with JAXB serialization of the root class `org.apache.camel.model.RoutesDefinition`. Already the first interface -> implementor descent to `CxfEndpoint` is useless IMO. The fact that `CxfEndpoint` implements `CamelContextAware` is no reason to think that reflective access to `CxfEndpoint` will ever help deserializing `RoutesDefinition`. Am I perhaps missing something? I am attaching all warnings in the same format: [hierarchy-registration-warnings.txt](https://github.com/user-attachments/files/24459359/hierarchy-registration-warnings.txt) @jerboaa could you please comment, whether the above was really intended by https://github.com/quarkusio/quarkus/pull/51432 ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
