-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move log4j-api to correct quarkus module and add condition for jackson-module-jaxb-annotations registrations #30018
Move log4j-api to correct quarkus module and add condition for jackson-module-jaxb-annotations registrations #30018
Conversation
/cc @gsmet(elasticsearch), @loicmathieu(elasticsearch), @yrodiere(elasticsearch) |
This comment has been minimized.
This comment has been minimized.
|
||
@BuildStep | ||
ReflectiveClassBuildItem register() { | ||
return new ReflectiveClassBuildItem(true, false, "com.fasterxml.jackson.module.jaxb.JaxbAnnotationIntrospector"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO Jackson stuff should be managed by the Jackson extension, which makes more sense here as resteasy-jackson
depends on jackson
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In theory I agree, but the thing is that the jackson
extension does not depend on com.fasterxml.jackson.module:jackson-module-jaxb-annotations
so there seems no need for it to register classes in it. On the other hand, resteasy-jackson
does depend on com.fasterxml.jackson.module:jackson-module-jaxb-annotations
(and is the reason we need to register the classes for reflection) so in practice it makes sense to me to move the registration there unless we expect people to manually add com.fasterxml.jackson.module:jackson-module-jaxb-annotations
as a depedency to their project and assume that using quarkus-jackson
would suffice to support it.
The Quarkus team should have better insight on this than me, since they probably have a better picture of how these extensions are used in the wild.
The alternative here is to keep the registration in quarkus-jackson
and only perform it when com.fasterxml.jackson.module:jackson-module-jaxb-annotations
is in the classpath.
.../io/quarkus/elasticsearch/restclient/common/deployment/ElasticsearchRestClientProcessor.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM for the Elasticsearch part.
I'm less sure about the Jackson part, since it's entirely possible that another extension makes use of jackson-module-jaxb-annotations
without using RestEasy. Ideally we'd have a quarkus-jackson-jaxb-annotations
extension, but that kind of strategy obviously cannot scale. I'd be in favor of not applying this change (the Jackson part) and instead finding some way of supressing warnings when we know they are not problematic, but I'll let more knowledgeable people decide.
As said in #30018 (comment):
Happy to proceed this way if there is consensus. |
+1 |
log4j-api is a dependency of elasticsearch-rest-high-level-client `log4j-api` is not always present when using the elasticsearch-rest-client-common extension as it's not a dependency of it. Instead, it is a dependency of elasticsearch-rest-high-level-client: ``` +- io.quarkus:quarkus-elasticsearch-rest-high-level-client:jar:999-SNAPSHOT:compile | +- ... | +- org.jboss.logmanager:log4j2-jboss-logmanager:jar:1.1.1.Final:compile | | \- org.apache.logging.log4j:log4j-api:jar:2.19.0:compile ``` `com.fasterxml.jackson.module.jaxb.JaxbAnnotationIntrospector` is not always present when using the quarkus-jackson extension as it's not a dependency of it. Instead, it is a dependency of quarkus-resteasy-jackson: ``` +- io.quarkus:quarkus-resteasy-jackson:jar:999-SNAPSHOT:compile | +- ... | +- org.jboss.resteasy:resteasy-jackson2-provider:jar:4.7.7.Final:compile | | +- ... | | +- com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.14.1:compile | | | +- com.fasterxml.jackson.jaxrs:jackson-jaxrs-base:jar:2.14.1:compile | | | \- com.fasterxml.jackson.module:jackson-module-jaxb-annotations:jar:2.14.1:compile ``` This results in failed attempts to register the class for reflection when using the `quarkus-jackson` extension without `jackson-module-jaxb-annotations` in the classpath. Since we expect users to manually include the artifact in their dependencies even when not using `quarkus-resteasy-jackson` we maintain the registration in the `quarkus-jackson` extension but only perform it when the artifact is present in the classpath.
c5009f1
to
690eeaf
Compare
I updated the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the Elasticsearch part, no change, LGTM.
Regarding the Jackson part, personally I would very much prefer to fix #29886 so that there's no warning when a class enabled for reflection is not found, be it only when we enable a "nowarning" flag on ReflectiveClassBuildItem
. Because I very much doubt we will want to jump through hoops like this every time we need to handle an optional dependency.
But if this solution is what @geoand prefers... I'll let @geoand approve ;)
x -> x.getGroupId().equals("com.fasterxml.jackson.module") | ||
&& x.getArtifactId().equals("jackson-module-jaxb-annotations"))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know I've asked elsewhere too so apologies for that, but did we reach a consensus about this pattern?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like there is no better way at the moment (see #29886 (comment))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
Thank for the (re-)review @yrodiere
IMHO that would not be a fix, but instead it would mean maintaining an old issue. I personally prefer having someone manually going through such errors and jumping through hooks from having classes that should be registered, not being registered without anyone noticing. |
log4j-api is a dependency of elasticsearch-rest-high-level-client
log4j-api
is not always present when using theelasticsearch-rest-client-common extension as it's not a dependency of
it. Instead, it is a dependency of elasticsearch-rest-high-level-client:
com.fasterxml.jackson.module.jaxb.JaxbAnnotationIntrospector
is notalways present when using the quarkus-jackson extension as it's not a
dependency of it. Instead, it is a dependency of
quarkus-resteasy-jackson:
This results in failed attempts to register the class for reflection
when using the
quarkus-jackson
extension withoutjackson-module-jaxb-annotations
in the classpath.Since we expect users to manually include the artifact in their
dependencies even when not using
quarkus-resteasy-jackson
we maintainthe registration in the
quarkus-jackson
extension but only perform itwhen the artifact is present in the classpath.
cc @essobedo
Fixes warnings appearing with #29886