Switch existing service implementation to a custom one before usage

[lucian-torje-siemens]

Hello,
I would like to be able to register my own service before it gets used by other registered service - e.g. CatalogService
It is possible to register my own service - the issue is that the other registered services using it, will still use the old one instead of my own.

The main idea is to register a service with priority - meaning that those special services (components) get registered before the default ones and custom ones cannot be overwritten once created (and will be injected instead of the default ones in other components).

[ndr-brt]

Hi, the way to achieve that is to register the "default" one with the @Provider(isDefault = true) annotation, then the custom service can be registered by an extension.
Right now a lot of services would need to be set as default, feel free to open issue/pr about specific services.
Ref: https://eclipse-dataspaceconnector.github.io/DataSpaceConnector/#/developer/dependency_resolution?id=provide-quotdefaultsquot

[jimmarino]

I don't follow what the concern is. The threadlocal approach would work exactly as in any managed Java container environment (c.f., the Java/Jakarta EE work manager, tracing libraries, etc., for example) - you need to make sure context information is propagated to different threads. For synchronous call blocks, set/unset the threadlocal. If async work is being done, propagate the information as part of an entity such as the TransferProcess.

[lucian-torje-siemens]

The missing piece of the puzzle was InheritableThreadLocal - see https://onecompiler.com/java/3ych24tw8

For me it still feels more natural to have a list of evaluate access policy filters - a list to which it should be possible to add more filters from custom code; nevertheless the thread-local storage approach will solve my problem. Thank you @jimmarino .

[jimmarino]

I would not do that since it has the potential for unintended side effects and will not work in all cases.

For synchronous code paths, set and clear the ThreadLocal at the ingress point using a filter and finally block. For async requests, attach relevant context to the entity or use your own thread dispatching mechanism like the Java WorkManager API.

There are examples of these approaches in the EDC codebase - .cf local transactions and metrics.

The approach I outlined also avoids rippling changes throughout the codebase that involve tunneling context-related data (e.g. 'extra' filters).

[lucian-torje-siemens]

Hello @ndr-brt @jimmarino,
I'm trying to replace the default InMemoryAssetIndex with my own custom implementation, unfortunately it is still using the default one marked with isDefault = true. What should be the right way to do this?

[ndr-brt]

@lucian-torje-siemens you can find the documentation about dependency resolution here: https://eclipse-dataspaceconnector.github.io/DataSpaceConnector/#/developer/dependency_resolution

if the documentation is not clear enough or there's something that's not working correctly, feel free to open an issue