Adding Spring Boot enhancements, Sring Data Repository, Testcontainers

[artur-ciocanu]

Description

This PR adds support for:

• Spring Boot Starters
• Spring Data Repository
• Spring Boot Testcontainers

Issue reference

We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.

Please reference the issue this PR will close: #1088

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation

[salaboy]

This depends on this: #1085 so please help us to merge that one first

[artur-ciocanu]

@salaboy I have addressed all your comments. Do let me know how to you want to proceed with Spring Boot related folders, do we rename them as per @ThomasVitale proposal like:

• dapr-data-spring-boot-starter
• dapr-messaging-spring-boot-starter
• etc

[salaboy]

@cicoyle @artursouza this test here: https://github.com/dapr/java-sdk/actions/runs/10578048505/job/29307323653?pr=1089
is failing with this error:

MethodInvokeIT.testInvokeTimeout:95 The message contains DEADLINE_EXCEEDED: DEADLINE_EXCEEDED: context deadline exceeded

But the assertion is done on contains "CallOptions deadline exceeded after" , which in my opinion is causing the flakiness as Daprd (the runtime) is not consistently returning the same error.

@cicoyle maybe you can help me to investigate what is the difference between "context deadline exceeded" and "CallOptions deadline exceeded after"

https://github.com/dapr/java-sdk/blob/master/sdk-tests/src/test/java/io/dapr/it/methodinvoke/grpc/MethodInvokeIT.java#L95

In my experience so far, this test is returning "CallOptions deadline exceeded after" one every 5 attempts.

[artur-ciocanu]

@cicoyle @artursouza this test here: https://github.com/dapr/java-sdk/actions/runs/10578048505/job/29307323653?pr=1089 is failing with this error:

MethodInvokeIT.testInvokeTimeout:95 The message contains DEADLINE_EXCEEDED: DEADLINE_EXCEEDED: context deadline exceeded

But the assertion is done on contains "CallOptions deadline exceeded after" , which in my opinion is causing the flakiness as Daprd (the runtime) is not consistently returning the same error.

@cicoyle maybe you can help me to investigate what is the difference between "context deadline exceeded" and "CallOptions deadline exceeded after"

https://github.com/dapr/java-sdk/blob/master/sdk-tests/src/test/java/io/dapr/it/methodinvoke/grpc/MethodInvokeIT.java#L95

In my experience so far, this test is returning "CallOptions deadline exceeded after" one every 5 attempts.

@salaboy, unless @artursouza and @cicoyle have a different opinion, I think asserting the code of StatusRuntimeException being equal to enum value DEADLINE_EXCEEDED(4) is more than enough.

I have adjusted the test, please take a look and let me know your thoughts.

[artur-ciocanu]

@artursouza and @cicoyle the build is 🟢. I will need your help with License Compliance, I don't think we use anything "dangerous", but we might need your approval.

Thank you!

[artursouza]

Pretty close. Have a few comments. Thanks a lot for your contribution.

[artursouza]

@artursouza and @cicoyle the build is 🟢. I will need your help with License Compliance, I don't think we use anything "dangerous", but we might need your approval.

Thank you!

The violation is coming from MySQL Connector/J 8.2.0 Community for using GPL 2.0.

Is there an alternative we can use?

[artur-ciocanu]

@artursouza and @cicoyle the build is 🟢. I will need your help with License Compliance, I don't think we use anything "dangerous", but we might need your approval.
Thank you!

The violation is coming from MySQL Connector/J 8.2.0 Community for using GPL 2.0.

Is there an alternative we can use?

I have created a CustomMySQLContainer implementation with a log based wait strategy and MySQL Connector J is no longer required.

[artur-ciocanu]

@artursouza and @salaboy you can check the SpotBugs failures here: https://github.com/dapr/java-sdk/actions/runs/10601809365/job/29382433463?pr=1089#step:16:3094. This is after I have removed SpotBugs exclude from dapr-spring module.

I don't think having those two exclusion rules for SpotBugs will lead to issues. As I already mentioned most of the classes that we inject via dependency injections are Spring Beans and there is nothing we can do about it.

Please let me know if you are OK with bringing back the SpotBugs exclusions.

[artur-ciocanu]

Pretty close. Have a few comments. Thanks a lot for your contribution.

@artursouza thanks a lot for your review. I have addressed or answered all your comments. I have provided an example regarding SpotBugs failures.

If everything looks good, could you please approve and merge. Thank you.

[artur-ciocanu]

@artursouza @salaboy @cicoyle the build is 🟢 I have addressed all the comments. Whenever you have a chance could you please take a look.

Thank you 🙇

[salaboy]

@artursouza and @salaboy you can check the SpotBugs failures here: https://github.com/dapr/java-sdk/actions/runs/10601809365/job/29382433463?pr=1089#step:16:3094. This is after I have removed SpotBugs exclude from dapr-spring module.

I don't think having those two exclusion rules for SpotBugs will lead to issues. As I already mentioned most of the classes that we inject via dependency injections are Spring Beans and there is nothing we can do about it.

Please let me know if you are OK with bringing back the SpotBugs exclusions.

@artursouza looking at the spotbug issues in the link provided I think there is no need to action anything, and having those exclude rules makes sense here.. Do you recommend maybe more concrete exclusion rules? I was looking at the approach suggested here: https://stackoverflow.com/questions/74127307/spring-dependency-injection-marked-unsafe-by-spotbugs but as some users mentioned, it is not worth doing that when this is for spring boot usage.

[artur-ciocanu]

@artursouza I have addressed all the review comments. The build is 🟢. I am not sure what's wrong with FOSSA. Could you please take another look and approve it.

Thank you 🙇 !