[
https://issues.apache.org/jira/browse/KUDU-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189059#comment-17189059
]
Peter Palaga commented on KUDU-3188:
------------------------------------
Thanks for the clarification [~granthenke].
bq. It sounds like the primary issue is that the Kudu client is not GraalVM
friendly/compatible. Can you help me to better understand if that is in-fact
the main issue and if we could contribute changes that help alleviate the issue
without "unshading" and effectively adding a new external dependency to the
Kudu client?
Yes, that would help to solve the problem we have in Camel Quarkus. It would be
great if you were interested in working towards that goal.
>From Camel Quarkus point of view, an ideal solution would be if you could
>provide a [Quarkus extension|https://quarkus.io/guides/writing-extensions].
>That would make the usage of kudu-client on Quarkus (incl. native mode) easier
>in general. It is up to you to decide whether this option makes sense to you.
There is perhaps another option, trough fixing the config in
{{meta-inf/native-image}}. I am not 100% sure whether this would help us in
Camel Quarkus, because I have never tried that, but there is some hope that it
would. As described in https://github.com/netty/netty/issues/8959 and the liked
PRs, Netty already provides valid GraalVM/native-image config in
{{meta-inf/native-image}} of their jars. That config is also present in
kudu-client.jar, but it does not match the shaded package names. So I guess, if
you'd apply some shading transformation to the data in
{{meta-inf/native-image}} the problem we have in Camel Quarkus would be solved
too. Because we already have a test, it would be quite easy to replace our
current solution with this. I'll try to find some time to check this idea.
> Consider to stop shading dependencies in kudu-client
> ----------------------------------------------------
>
> Key: KUDU-3188
> URL: https://issues.apache.org/jira/browse/KUDU-3188
> Project: Kudu
> Issue Type: Improvement
> Components: client
> Reporter: Peter Palaga
> Priority: Major
>
> My motivation for asking this is the following:
> I work on Apache Camel Quarkus, where we basically port Camel components to
> Quarkus incl. native compilation using GraalVM. Java code typically needs to
> get prepared for native compilation with GraalVM by registering classes for
> reflection, requesting class initialization at runtime, setting class/method
> substitutions, etc.
> As you may know there is [Kudu Camel
> component|https://camel.apache.org/components/latest/kudu-component.html]
> that is using kudu-client internally. Porting it to GraalVM is currently
> quite cumbersome due to shading.
> If Netty was a standard dependency of kudu-client, we could simply re-use the
> work done in
> [quarkus-netty-extension|https://github.com/quarkusio/quarkus/blob/master/extensions/netty/deployment/src/main/java/io/quarkus/netty/deployment/NettyProcessor.java]
> by depending on it in camel-quarkus-kudu. But because netty is shaded in
> kudu-client, we have no better choice than copy & adapt all the
> quarkus-netty-extension code to Camel Quarkus and maintain it there:
> https://github.com/apache/camel-quarkus/pull/1667/files Needless to say, we'd
> prefer not maintaining the copied code in Camel Quarkus.
> So I'd like to ask whether there is any chance to stop shading Netty and
> possibly other kudu-client dependencies.
> I wonder which reasons you had for introducing shading originally?
> I know that compatibility of Netty between micro releases used to be quite
> flaky in the past. The last comment in
> https://github.com/netty/netty/issues/7586 brings some hope that it is not an
> issue anymore.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
