feat: Support CRaC priming of powertools validation

[kjswaruph]

Summary

Adds support for CRaC priming in the Powertools validation module.

Changes

Please provide a summary of what's being changed

• Add org.crac dependency and generate-classesloaded-file profile in pom.xml
• Add classesloaded.txt in src/main/resources for automatic class preloading
• Update ValidationConfig to register for Crac resource
• Update spotbugs-exclude.xml to suppress RV_RETURN_VALUE_IGNORED_NO_SIDE_EFFECT spotbug error caused by getJmesPath() and getFactory() in beforeCheckpoint method

Please add the issue number below, if no issue is present the PR might get blocked and not be reviewed

Issue number: #2005

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[phipag]

Hey @kjswaruph,

thank you so much for contribution. The priming logic looks good to me. I tested it in my AWS account using SNAPSTART enabled for our validation example.

I found some points that we need to improve / clarify:

(1) Execution of priming logic

The priming logic will only run if I explicitly reference the ValidationConfig in my Lambda handler constructor. For the example above, the priming logic does not execute if I remove this constructor:

    public InboundValidation() {
        ValidationConfig.get(); // Ensure ValidationConfig is loaded for SnapStart
    }

The reason for this is that AspectJ compile-time weaving transforms the @Validation annotated Lambda handler at compile time which will not cause an object reference at initialization time when SNAPSTART takes a memory snapshot.

Given the fact that the user can use the Validation utility solely using @Validation annotation we need to document this in our documentation and state that an explicit reference to ValidationConfig is needed. This is already the case when the user wants to apply some customization to the validation. For example this docs example:

    static {
        ObjectMapper objectMapper = ValidationConfig.get().getObjectMapper();
        // update (de)serializationConfig or other properties
    }

This will invoke your priming logic since a reference to ValidationConfig exists at runtime classloading time. Therefore, I think ValidationConfig is the right place to add this priming logic.

Can you add a documentation at the end of the documentation about this? You can create a new section "advanced" with a "Snapstart priming" subsection:

Advanced
└── Snapstart priming

In the Snapstart priming subsection, can you explain that we need a reference to ValidationConfig to allow the library to register before Snapstart takes a memory snapshot and give a code example similar to the one I shared above? Let me know if you want me to add the documentation – happy to do it.

(2) Unit testing

Can you write a unit test that calls the beforeCheckpoint and afterRestore hooks simply asserting that no exception is raised? This is good to catch any exceptions when we make changes.

(3) Spotbugs

    <Match>
        <Bug pattern="RV_RETURN_VALUE_IGNORED_NO_SIDE_EFFECT"/>
        <Class name="software.amazon.lambda.powertools.validation.ValidationConfig"/>
        <Method name="beforeCheckpoint"/>
    </Match>

Can you explain why this is needed?

Update: I understand now. The return values of the priming calls are ignored which is ok because the rule is scoped to beforeCheckpoint. Thanks!

[kjswaruph]

Hey @phipag , thanks for the review and clarification on the priming logic. I’ve updated the Validation docs with the SnapStart priming subsection and added the unit tests. Please take another look when you have time, tell me if there 's any nedd to change wording in the docs or additional changes.

[phipag]

~~Hey @kjswaruph, thank you so much for getting back to me so quickly. ~~

Can you take a look at these three SonarCube findings and send an update? https://sonarcloud.io/project/issues?id=aws-powertools_powertools-lambda-java&pullRequest=2081&issueStatuses=OPEN,CONFIRMED&sinceLeakPeriod=true

Done, thanks ✅

I will read the docs in the meantime and suggest changes that you can directly commit in the GitHub UI.

[phipag]

Thanks @kjswaruph. Just a small suggestion for the docs wording.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
1 Accepted issue

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[kjswaruph]

@phipag Done, applied the recommended suggestions.

[phipag]

Awesome, @kjswaruph! Once the CI passes I will merge this PR. It looks good to me.

Congratulations on your first contribution to Powertools for AWS Lambda (Java)!!! 🥳

[kjswaruph]

Thanks @phipag, appreciate the review and the guidance. Learnt a lot of new things from this, would be happy to pick up more issues if you have suggestions.

[phipag]

Thanks @phipag, appreciate the review and the guidance. Learnt a lot of new things from this, would be happy to pick up more issues if you have suggestions.

Happy to hear you learnt a lot, @kjswaruph! Absolutely, feel free to checkout our good-first-issue and/or help-wanted labeled issues that are unassigned: https://github.com/aws-powertools/powertools-lambda-java/issues?q=is%3Aissue%20state%3Aopen%20label%3Agood-first-issue

There are a number of more CRaC priming issues if you are interested in working on this.

I also meant to ask: What did you think of the Priming documentation for developers? Was it clear to you? Do you have any suggestions for improvement?

[kjswaruph]

The priming documentation was clear to me and it helped me in getting started with this issue. I think overall the documentation is good and clear.