Setting default props for DaprClient

[salaboy]

Description

Setting the default values for DaprClient Spring Boot properties.

Issue reference

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

Please reference the issue this PR will close: #1566

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

[mcruzdev]

LGTM

[salaboy]

@dapr/maintainers-java-sdk @dapr/approvers-java-sdk without setting these defaults, Spring Boot doesn't know where to find Dapr when running the application. This force the user to set the properties when they shouldn't.

[siri-varma]

LGTM

[artur-ciocanu]

@salaboy I like the idea, however I think the endpoint syntax should be a little bit different. It should include the port as well.

I have looked in these places:

• GRPC endpoint -

  java-sdk/sdk/src/main/java/io/dapr/utils/NetworkUtils.java

  Line 277 in 222b9a0

  if ((grpcEndpoint != null) && !grpcEndpoint.isEmpty()) {

• HTTP endpoint -

  java-sdk/sdk/src/main/java/io/dapr/client/DaprHttpBuilder.java

  Line 76 in 222b9a0

  return new DaprHttp(endpoint, apiToken, readTimeout, HTTP_CLIENT);

In both of these places the expectation is that we provide the port as part of endpoint.

[artur-ciocanu]

I wondering if an endpoints shouldn't have the port. As far as I remember there is some parsing logic in the network utils.

[salaboy]

@artur-ciocanu yeah.. I have this constant feeling that this is not aligned all over the place.. but I didn't wanted to add more changes to this PR. Maybe we need another issue to track this alignment. Right now, this is just setting the default values.

[artur-ciocanu]

We could remove unnecessary new lines.

[artur-ciocanu]

@salaboy I see that the build steps are timing out could you please check what might be the issue.

Thank you!

[cicoyle]

I second @artur-ciocanu's comments here - looks like its causing issues with CI - this should be resolved before its merged.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.42%. Comparing base (d759c53) to head (fd621f2).
⚠️ Report is 234 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1567      +/-   ##
============================================
+ Coverage     76.91%   78.42%   +1.50%     
- Complexity     1592     1927     +335     
============================================
  Files           145      216      +71     
  Lines          4843     5872    +1029     
  Branches        562      658      +96     
============================================
+ Hits           3725     4605     +880     
- Misses          821      926     +105     
- Partials        297      341      +44     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cicoyle]

There looks to be an endpoint misalignment/misconfiguration going on causing CI to hang.

You may need to tweak things after confirming how the daprworkflowclient is constructed using the buildgrpcmanagedchannel. I think its coming from this file NetworkUtils.java as I see we have this check which might be were that 443 is coming from in the logs which would be the wrong port with this configuration:

        String parsedPort = matcher.group("port");
        if (parsedPort != null) {
          port = Integer.parseInt(parsedPort);
        } else {
          // This implements default port as 80 for http for backwards compatibility.
          port = http ? 80 : 443;
        }