I have added “thundra-lambda-audit” dependency but cannot trace my Lambda application internals automatically, why?
“thundra-lambda-audit” module only provides support for tracing invocations automatically, not for the Lambda application internals. You can still instrument your applications manually but for automated instrumentation support by annotation and environment variable, you need to add “thundra-audit-instrument” module into your dependencies for bytecode level instrumentation. See https://docs.thundra.io/docs/java-audit-trace-support for more details.
I have added “thundra-lambda-log” dependency, added Thundra’s log4j appender but cannot see logs in the invocation, why?
com.opsgenie.thundra.log.MonitoredLogAppender publishes log events from any logger if the logger is
com.opsgenie.thundra.log.MonitoredLogger log events from other
org.apache.log4j.Loggers are ignored. See https://docs.thundra.io/docs/java-log-support for more information.
Thundra has a plugin-based architecture and discovers its plugins based on Java Service API (https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html) protocol. So the plugins are defined under
META-INF/services folder and discovered by Thundra’s core engine from there. Since there might be multiple plugin (or service) definitions of the same plugin interface (so has same plugin definition file name), the plugin definitions must be merged. So Thundra has its own annotation processor to be invoked at compile time by “javac” for merging service definitions natively without any extra configuration. However annotation processors might not be invoked by some build tools or development environments. For this reason, it is also advised to add the required configurations to your build tools for merging service definitions at build time explicitly. See https://docs.thundra.io/docs/java-installation for more information.
I have implemented my Lambda handler from
ThundraLambdaRequestHandler but I am getting
java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to ..., why?
For your handler config, you SHOULDN’T specify method name (
handleRequest) but just handler class full name. Because if method name is specified, AWS Lambda tries to resolve the request type from method arguments by Java Reflection API. But since generic types are not available at method level, requests data is deserialized into
java.util.Map instance and this leads to
ClassCastExceptions while passing request to your handler. Therefore, at your handler config, just specify handler full class name without method name (which it is not needed).