feat: implement domain scoping

[jarebudev]

This PR

• implements most of #843 (see notes as have currently left out the 2 experimental requirements)

Related Issues

Resolves #843

Notes

As this change was getting a bit large I wanted to make sure that the main requirements of the issue were implemented correctly first of all so I've not yet done the two requirements that are listed as experimental.

I can either add them into this PR or split them out into a separate issue, either way is fine with me, but wanted to check that this change is on the right path first of all.

Follow-up Tasks

I've not implemented these two requirements

• Requirement 3.2.2.3: The API MUST have a method for setting evaluation context for a domain.
• Requirement 3.2.2.4: The API MUST have a mechanism to manage evaluation context for an associated domain.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 95.27%. Comparing base (4ea74d8) to head (034b066).

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #934      +/-   ##
============================================
+ Coverage     95.03%   95.27%   +0.23%     
- Complexity      391      393       +2     
============================================
  Files            37       38       +1     
  Lines           887      888       +1     
  Branches         54       54              
============================================
+ Hits            843      846       +3     
+ Misses           24       23       -1     
+ Partials         20       19       -1     

Flag	Coverage Δ
unittests	95.27% <100.00%> (+0.23%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[toddbaert]

I've not implemented these two requirements

Requirement 3.2.2.3: The API MUST have a method for setting evaluation context for a domain. Requirement 3.2.2.4: The API MUST have a mechanism to manage evaluation context for an associated domain.

These requirements only apply to the static context SDKs (read: client-side SDKs) which Java is not, so you can skip them!

[Kavindu-Dodan]

Thanks @jarebudev ! This looks great, there's only a few minor changes that need to be made non-breaking, then I can approve.

Thanks again for your time and effort!

Same opinion, we can make the change non-breaking. I proposed this

[jarebudev]

Thanks @jarebudev ! This looks great, there's only a few minor changes that need to be made non-breaking, then I can approve. Thanks again for your time and effort!

Same opinion, we can make the change non-breaking. I proposed this

Thanks both for your feedback - I'll apply your suggestions :)

[Kavindu-Dodan]

@jarebudev thank you for the latest change. I have this doubt and I will approve once I clarify this with @toddbaert :)

I am happy with the rest

[Kavindu-Dodan]

Approved. Agree with your deprecation suggestion @Kavindu-Dodan

Unfortunately this was not straightforward. We used same Metadata interface for both clients and providers. Given that domains are part of Client, I had to introduce a new interface ClientMetadata. See this commit https://github.com/open-feature/java-sdk/pull/934/commits/2d2c5cfe708cb0899b4b8b2d39735239a4292325

[toddbaert]

Approved. Agree with your deprecation suggestion @Kavindu-Dodan

Unfortunately this was not straightforward. We used same Metadata interface for both clients and providers. Given that domains are part of Client, I had to introduce a new interface ClientMetadata. See this commit 2d2c5cf

Isn't this change breaking since we changed a return type?

[Kavindu-Dodan]

Approved. Agree with your deprecation suggestion @Kavindu-Dodan

Unfortunately this was not straightforward. We used same Metadata interface for both clients and providers. Given that domains are part of Client, I had to introduce a new interface ClientMetadata. See this commit 2d2c5cf

Isn't this change breaking since we changed a return type?

Yes, could consider as a breaking change as Client now use ClientMetadata. But if someone use lambda, then it's a simple functional interface with a string return, so shouldn't notice it.

[Kavindu-Dodan]

Approved. Agree with your deprecation suggestion @Kavindu-Dodan

Unfortunately this was not straightforward. We used same Metadata interface for both clients and providers. Given that domains are part of Client, I had to introduce a new interface ClientMetadata. See this commit 2d2c5cf

Isn't this change breaking since we changed a return type?

Yes, could consider as a breaking change as Client now use ClientMetadata. But if someone use lambda, then it's a simple functional interface with a string return, so shouldn't notice it.

I provided more update here with https://github.com/open-feature/java-sdk/pull/934/commits/12f7f4dad04c5c95e6cab22d910eedf947b089d9

ClientMetadata expose a deprecated getName() so that wherever users have client.getMetadata().getName() is no longer broken. Internally, the returning string matches the domain.

[sonarqubecloud[bot]]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud