Skip to content
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

quarkiverse's LambdaBuildTimeConfig interface conflicts with io.quarkus's LambdaBuildTimeConfig class #1209

Open
emakunin opened this issue Apr 7, 2024 · 3 comments · May be fixed by #1267

Comments

@emakunin
Copy link

emakunin commented Apr 7, 2024

Hello,

I'm trying to use quarkus-amazon-lambda from io.quarkiverse .amazonservices to inject AWS lambda client in a service that uses

       <dependency>
            <!-- AWS Lambda Client injection -->
            <groupId>io.quarkiverse.amazonservices</groupId>
            <artifactId>quarkus-amazon-lambda</artifactId>
        </dependency>

        <dependency>
             <!-- My service or some async job lambda -->
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-amazon-lambda-rest</artifactId> <!-- or just quarkus-lambda -->
       <dependency>

I tried all available versions of quarkus and quarkiverse and theirs combinations. However it doesn't work. You can try with the version combinations mentioned in https://github.com/quarkiverse/quarkus-amazon-services.

As a result my build fails with

[ERROR] Failed to execute goal io.quarkus.platform:quarkus-maven-plugin:3.8.1:build (default) on project inventory-management-rest: Failed to build quarkus application: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
[ERROR] [error]: Build step io.quarkus.amazon.lambda.deployment.LambdaProcessor#setupClient threw an exception: java.lang.IncompatibleClassChangeError: Found class io.quarkus.amazon.lambda.runtime.LambdaBuildTimeConfig, but interface was expected
[ERROR] at io.quarkus.amazon.lambda.deployment.LambdaProcessor.setupClient(LambdaProcessor.java:104)
[ERROR] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
[ERROR] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.base/java.lang.reflect.Method.invoke(Method.java:568)
[ERROR] at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:849)
[ERROR] at io.quarkus.builder.BuildContext.run(BuildContext.java:256)
[ERROR] at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
[ERROR] at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
[ERROR] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1538)
[ERROR] at java.base/java.lang.Thread.run(Thread.java:840)
[ERROR] at org.jboss.threads.JBossThread.run(JBossThread.java:501)
[ERROR] -> [Help 1]

In this commit you added LambdaBuildTimeConfig interface that conflicts with the LambdaBuildTimeConfig class used by io.quarkus. See io quarkus class LambdaBuildTimeConfig

I guess the config interface package or the interface name need to be modified. So far a workaround is to not use quarkiverse and inject clients manually.

@emakunin emakunin changed the title Quarkiverse lambda client conflicts with io.quarkus lambda quarkiverse's LambdaBuildTimeConfig interface conflicts with io.quarkus's LambdaBuildTimeConfig class Apr 7, 2024
@scrocquesel
Copy link
Member

@radcortez Is is expected that we cannot share the root prefix in two different packages ? Is it because in we use interface mapping in the extension while quarkus is using class mapping.

@scrocquesel
Copy link
Member

It seems there are limited solutions available:

  • Alter the configuration prefix to "lambdaclient." However, this adjustment would deviate from the convention used for all other extensions, where the artifact ID of the AWS package serves as the key.
  • Modify the package name prefix to io.quarkiverse. Historically, "io.quarkus" was utilized when the project was under the umbrella of "quarkus/quarkus." While this change should be seamless, it might pose issues for extensions like S3 and DynamoDB, which offer custom annotations.

I would vote for option 2.

@scrocquesel scrocquesel linked a pull request May 19, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants