Enable configuration of clients independent of local environment.

[hgo-ds]

As a consumer of the IRS registry client library org.eclipse.tractusx.irs:irs-registry-client
I want to be able to setup Clients which are part of the IRS-Library independent of the configured Spring-Profile,
so that using IRS registry client library in a local setup can be configured as in real deployment and can connect to a real or mocked service.

Hints / Details

• child of Resiliency Measurements sig-release#218
  • Using @Profile("local") in

    item-relationship-service/irs-registry-client/src/main/java/org/eclipse/tractusx/irs/registryclient/central/DigitalTwinRegistryClientLocalStub.java

    Line 40 in 4bb7276

    @Profile({ "local",

    
    prevents configuring org.eclipse.tractusx.irs.semanticshub.DigitalTwinRegistryClient against an external service in environments declared as local.

• See https://github.com/search?q=repo%3Aeclipse-tractusx%2Fitem-relationship-service%20%40profile&type=code for possible occurrences.

• Consider removing all @Profile("local") from the code and replacing them with clearly defined feature flags that can be controlled from the application configuration.

Outcome / Acceptance Criteria

• Usage and implementation of clients is independent of the configured Spring-Profile.

[jzbmw]

@hgo-ds we have some questions regarding this request:

• Is the issue of the Profile the naming convention?
• Is it possible for you to overwrite the bean with primary annotation?

is the Problem, that we use the local profile in a way that we use ist to mock or test topics?

[jzbmw]

Tasks

• define, clarify new Application Profiles with ( stub, test, stubtest, local)
• refactor Profile's
• refactor documentation regarding profiling within IRS
• clarify @ds-mwesener with Trace-X if it affects their deployment
• check environments if there are dependencies

[ds-mwesener]

As we do not use profiles at all, there is currently no impact on trace-x. Either way the provided suggestion would not cause any issues.

[mkanal]

My rough suggestion would be to completely remove the use of "local" profiles etc. in the code and to establish a dedicated feature flag for the desired function, e.g. "enableDigitalTwinRegistryClientStub", preferably with a meaningful default value.

These feature flags are added as properties to the respective application.yaml files as required and can therefore be used independently of the respective profile.

Implementation in the code then with @ConditionalOnProperty on the bean that you want to activate here.

--

This does not prevent the use of profiles in the Spring environment, on the contrary, the configuration of the respective features is only lifted or collected in a central location (.yaml file) and the user has all the freedom independent of the configured profile.

This would be a relief IMHO, especially for libraries that are used in third-party applications.

Translated with www.DeepL.com/Translator (free version)

[hgo-ds]

@jzbmw
Basically, using @Profile within the code to control behavior of the library i.e. to establish mocks for certain setups like tests is the issue.
As the desired implementation for our use case is also part of the library, using primary is no option.
The naming itself is not the issue, it's just the kind how it is implemented.

My detail thoughts are covered here #202 (comment)

[mkanal]

Due to the @Profile-IRS fuzziness, however, we are unfortunately not able to start a "real" TRX in the local environment with profile local (and the associated configuration via application-local.yaml) as the DigitalTwinRegistryClientLocalStub is then instantiated in the IRS instead of the DigitalTwinRegistryClientImpl, for example.

[ds-jhartmann]

Planning 2

• check if we can move the stubs to the IRS module
• if not, rename the profile to something unique

[ds-psosnowski]

@hgo-ds Hello
All profile-conditional bean creation in irs-registry-client has been moved to irs-api .
Please check and let us know if this is working as you expected. Library version is 1.5.0

[hgo-ds]

Thanks @ds-psosnowski for providing the fix.

Unfortunately, it's not released yet.

https://repo1.maven.org/maven2/org/eclipse/tractusx/irs/irs-registry-client/

Only available in Repo: orgeclipsetractusx-1039 (staging: closed) https://oss.sonatype.org/#nexus-search;gav~~irs-registry-client~1.5.0~~

First tests with release 1.5.0-SNAPSHOT where fine so far.

What is the timetable for the release of the artifact?
Is there anything we can do?

[ds-jhartmann]

Hi @hgo-ds
seems like something went wrong in the staging process. I started the workflow again and it was successful this time. The artifact should be available within the next 1 or 2 hours.
Sorry for the inconvenience.

[hgo-ds]

This is looking very fine now, thanks for support @ds-jhartmann.

Tests are in progress.