refactor: remove TransferRequest properties attribute

[hamidonos]

Feature Request

The TransferRequest object contains a properties attribute which has been marked as deprecated already.
It's being mapped inside the JsonObjectToTransferRequestTransformer but it's not used anywhere else.

Which Areas Would Be Affected?

transfer process

Why Is the Feature Desired?

clean up

Solution Proposal

remove the properties attribute and references to it

[AbbasSalloum]

Hey I want to pick up this issue

Thank you

[AbbasSalloum]

@AbbasSalloum

[hamidonos]

@AbbasSalloum I think you can start with this one
but let's wait until @ndr-brt gives green light too

[SebastianOpriel]

@efiege might be a breaking change we need to take into account

[hamidonos]

@SebastianOpriel the properties field has no real usage anymore since the privateProperties field has been added by this PR #3368

The properties field is deprecated (see this )

This task is a further clean up of #3368

[SebastianOpriel]

Okay good to know. @efiege this means that Catena-X shall have handled this already, since the change was introduced in https://github.com/eclipse-edc/Connector/releases/tag/v0.2.1

[ndr-brt]

given that it was deprecated in version 0.2.0, it can be removed now, as the deprecation period of 2 milestones has been passed.

[AbbasSalloum]

Execution failed for task ':spi:common:policy-model:compileJava'.

Error while evaluating property 'javaCompiler' of task ':spi:common:policy-model:compileJava'.
Failed to calculate the value of task ':spi:common:policy-model:compileJava' property 'javaCompiler'.
> No matching toolchains found for requested specification: {languageVersion=17, vendor=any, implementation=vendor-specific}.
> No locally installed toolchains match (see https://docs.gradle.org/8.0/userguide/toolchains.html#sec:auto_detection) and toolchain download repositories have not been configured (see https://docs.gradle.org/8.0/userguide/toolchains.html#sub:download_repositories).

Hey im getting this error while building the project i think its because im using java 17 any ideas how to fix it or should i just change my java version ?

Thank you

[hamidonos]

@AbbasSalloum did you resolve your issue?
You can direct message me on Matrix. I can help you

[AbbasSalloum]

sorry not sure what matrix is

…

On Fri, Dec 1, 2023 at 8:12 AM hamidonos ***@***.***> wrote: @AbbasSalloum <https://github.com/AbbasSalloum> did you resolve your issue? You can direct message me on Matrix. I can help you — Reply to this email directly, view it on GitHub <#3639 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APA2OPEZ6Z7M6JB3NGINLA3YHHJTPAVCNFSM6AAAAAA7WKENCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZWGA4TQMBTHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[hamidonos]

Execution failed for task ':spi:common:policy-model:compileJava'.

Error while evaluating property 'javaCompiler' of task ':spi:common:policy-model:compileJava'.
Failed to calculate the value of task ':spi:common:policy-model:compileJava' property 'javaCompiler'.

No matching toolchains found for requested specification: {languageVersion=17, vendor=any, implementation=vendor-specific}.
No locally installed toolchains match (see https://docs.gradle.org/8.0/userguide/toolchains.html#sec:auto_detection) and toolchain download repositories have not been configured (see https://docs.gradle.org/8.0/userguide/toolchains.html#sub:download_repositories).

Hey im getting this error while building the project i think its because im using java 17 any ideas how to fix it or should i just change my java version ?

Thank you

Java 17 is fine
What SDK are you using?
How did you try to build the project exactly?

[ndr-brt]

@AbbasSalloum I'm not sure this is the right place to discuss about compilation errors, only comments related to the issue please.

[github-actions]

This issue is stale because it has been open for 14 days with no activity.

[github-actions]

This issue is stale because it has been open for 14 days with no activity.

[github-actions]

This issue is stale because it has been open for 14 days with no activity.

[git-masoud]

HttpParamsDecorator relies on properties in the transfer request. These properties are valuable when assets need to adjust content based on consumer input. But, because recent changes in the transfer request and dsp protocol leave these properties always empty, HttpParamsDecorator seems pointless now. Does my assessment correct ?

[ndr-brt]

no, it doesn't, according to the signature it relies on DataFlowStartMessage and HttpDataAddress.

anyway, this issue is already resolved: TransferRequest does not have a properties field anymore.

[ununhexium]

We currently use these private properties to restore the assets' parameterization feature in the provider push use-case, via a workaround in the Connector v0.2.1.
This feature got removed when switching to the DSP protocol as it doesn't support it but our clients use it.

Does this deletion of properties imply that this use-case won't be supported at all in the future?

[ndr-brt]

the transfer properties are not described in DSP so they were removed, this issue was just about clean them up from the TransferRequest object, but as you said they were unused since >0.2
To store private data about a transfer privateProperties can be used, but they won't be passed to the provider in any way.

[jimmarino]

We currently use these private properties to restore the assets' parameterization feature in the provider push use-case, via a workaround in the Connector v0.2.1. This feature got removed when switching to the DSP protocol as it doesn't support it but our clients use it.

Does this deletion of properties imply that this use-case won't be supported at all in the future?

Can you explain what you mean by this? What use case are you trying to solve?

[git-masoud]

We currently use these private properties to restore the assets' parameterization feature in the provider push use-case, via a workaround in the Connector v0.2.1. This feature got removed when switching to the DSP protocol as it doesn't support it but our clients use it.
Does this deletion of properties imply that this use-case won't be supported at all in the future?

Can you explain what you mean by this? What use case are you trying to solve?

We currently use these private properties to restore the assets' parameterization feature in the provider push use-case, via a workaround in the Connector v0.2.1. This feature got removed when switching to the DSP protocol as it doesn't support it but our clients use it.
Does this deletion of properties imply that this use-case won't be supported at all in the future?

Can you explain what you mean by this? What use case are you trying to solve?

I can describe a simple use case:
A provider has a generic API that provides the location and status of rental bikes. The consumers of this API can apply simple filters by sending parameters like radius, longitude, and latitude to the API endpoint to only get the data of the required region.
in the older version of edc, we could enable proxyQueryParams in the asset definition and ask the consumers to pass the radius, longitude, and latitude as extra properties in the transferProcessRequest. HTTP decorator in the Dataplane HTTP , later would add those properties in the provider side as query parameters to the API request.

[jimmarino]

Can you explain what you mean by this? What use case are you trying to solve?

I can describe a simple use case: A provider has a generic API that provides the location and status of rental bikes. The consumers of this API can apply simple filters by sending parameters like radius, longitude, and latitude to the API endpoint to only get the data of the required region. in the older version of edc, we could enable proxyQueryParams in the asset definition and ask the consumers to pass the radius, longitude, and latitude as extra properties in the transferProcessRequest. HTTP decorator in the Dataplane HTTP , later would add those properties in the provider side as query parameters to the API request.

That way of modeling the requirement mixes concerns. I would create an asset, and either have the parameters passed explicitly by the client as part of the data plane API being used or create a proxy mapping in the data plane that passes the parameters as part of the forwarded request.