AmazonLambdaRecorder Handler Discovery Erroneously Considers Decorators

[gilday]

Describe the bug

In the absence of any configuration, the io.quarkus.amazon.lambda.runtime.AmazonLambdaRecorder automatically discovers the application's single RequestHandler or RequestStreamHandler class. If multiple candidate types are discovered this way, then the AmazonLambdaRecorder errors:

java.lang.RuntimeException: Multiple handler classes, either specify the quarkus.lambda.handler property, or make sure there is only a single com.amazonaws.services.lambda.runtime.RequestHandler or, com.amazonaws.services.lambda.runtime.RequestStreamHandler implementation in the deployment

Presently, this type discovery logic considers RequestHandler and RequestStreamHandler types that are CDI decorators (i.e. annotated with jakarta.decorator.Decorator). This doesn't seem right, because the decorator type itself can never be the request handler, absent the handler it decorates.

This behavior is a problem for application developers that want to seamlessly introduce new decorators for their Lambda function handlers, because the introduction of the decorator unexpectedly requires the application develop to name all lambda function handler type beans and introduce the quarkus.lambda.handler configuration property.

Expected behavior

AmazonLambdaRecorder ignores CDI decorator types in its RequestHandler and RequestStreamHandler type discovery. Therefore, it selects the first not-decorator RequestHandler or RequestStreamHandler bean, and, of course, that is decorated with any applicable jakarta.decorator.Decorator beans that may exist.

Actual behavior

Quarkus reports a conflict between the RequestHandler or RequestStreamHandler and the decorator, and this conflict must be resolved using quarkus.lambda.handler to specify the not-decorator type.

How to Reproduce?

lambda-request-handler-decorator.zip

Output of uname -a or ver

Darwin pixee-mbp-gilday.localdomain 22.5.0 Darwin Kernel Version 22.5.0: Thu Jun 8 22:22:20 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6000 arm64

Output of java -version

openjdk version "17.0.7" 2023-04-18 OpenJDK Runtime Environment Temurin-17.0.7+7 (build 17.0.7+7) OpenJDK 64-Bit Server VM Temurin-17.0.7+7 (build 17.0.7+7, mixed mode)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

3.2.0.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39) Maven home: /Users/jgilday/.m2/wrapper/dists/apache-maven-3.8.8-bin/67c30f74/apache-maven-3.8.8 Java version: 17.0.7, vendor: Eclipse Adoptium, runtime: /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac"

Additional information

No response

[quarkus-bot]

/cc @matejvasek (amazon-lambda), @patriot1burke (amazon-lambda)

[gilday]

This is also an issue at build time for Lambda functions that use the AWS Lambda HTTP extension: decorator beans on the classpath that would otherwise do nothing cause build failures.

Caused by: io.quarkus.builder.BuildException: Build failure: Multiple handler classes.  You have a custom handler class and the AWS Lambda HTTP extension.  Please remove one of them from your deployment.
        at io.quarkus.amazon.lambda.deployment.AmazonLambdaProcessor.discover(AmazonLambdaProcessor.java:88)

[gsmet]

It took a while, sorry, but I created #44155 to hopefully take care of it.

Thanks for the awesome reproducer!