jsinovassin opened a new pull request, #861: URL: https://github.com/apache/unomi/pull/861
[UNOMI-980](https://issues.apache.org/jira/browse/UNOMI-980) ### What this changes The compatibility mode lets a client written before Unomi 3.1 keep working with no change on its side. It refused every request until an operator created a tenant by hand, which is a step no earlier version asked for: ``` ERROR AuthenticationFilter - V2 compatibility mode: configured default tenant 'default' does not exist ``` Three arms, all in that mode. **Create the tenant the mode runs on.** The new `TenantService.getOrCreateTenant` is synchronized, and it re-reads the tenant when a concurrent creation wins the race. Several nodes starting together all get the tenant, and only one creation happens. **Drop the tenant identifier setting.** The mode read the setting in two places, and both sit inside the method that runs only when the mode is on. A client from before 3.1 knows no tenant, so it never names one, and nothing outside the filter read the value. The identifier is now a constant. Two unreachable branches go with the setting. Each call site tested the value for blankness, while `modified()` already fell back to `default`. The two branches also disagreed: a blank value denied every public request on one path, and switched to the system context on the other. **Rename the mode.** Unomi 3.0.0 and 3.0.1 carry no tenant either, so a 3.0.1 client meets the same wall as a V2 client. The old name named the wrong thing. `v2.compatibilitymode.enabled` becomes `singletenantcompatibility.enabled`. The 3.1 line is not released, so the key can still change. ### Tests `V2CompatibilityModeIT` becomes `SingleTenantCompatibilityModeIT`. Its two tests that existed only to exercise the removed setting are gone. Two tests built a fixture through the services, which puts it in the tenant `BaseIT` works in. They then read the fixture back through the compatibility path, which runs on its own tenant. `testV2ModeBehavior` now reads back the profile its own V2-style request created. `setUp` now creates the test scope in the compatibility tenant as well, and puts the execution context back afterwards. ``` itests SingleTenantCompatibilityModeIT 3 tests, 0 failures unomi-rest unit tests 120 tests, 0 failures ``` The full integration suite has not been run. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
