What about multiple ResourceDefinitionGenerators for a TransferProcess?

[florianrusch-zf]

While digging around in the code I identified, that theoretically there could be multiple ResourceDefinitionGenerator implementations which generates ResourceDefinition's for the same TransferProcess. Is this behaviour correct? Is this a feature/use-case?

https://github.com/eclipse-dataspaceconnector/DataSpaceConnector/blob/acd47bdfc841bb754cc7e2bf6279f70bf8481eef/core/transfer/src/main/java/org/eclipse/dataspaceconnector/transfer/core/provision/ResourceManifestGeneratorImpl.java#L66-L77

I would imagine that the same mechanism as already used to identify the correct DataFlowController would be better (especially the lines 47-48). Or I'm wrong at this point?
https://github.com/eclipse-dataspaceconnector/DataSpaceConnector/blob/54aade6ea6c3b1225c2c387a37953c082b049c9b/core/transfer/src/main/java/org/eclipse/dataspaceconnector/transfer/core/flow/DataFlowManagerImpl.java#L42-L54

[jimmarino]

The current behavior is by design. Multiple resources may be required.

[ndr-brt]

@jimmarino I'm not sure about this, Ok for multiple resources, but what about a single resource created on a connector that supports two different destination types? Like "HttpProxy" and "AmazonS3", in this case 2 resources are created and the provisioner will try to provision two resources, otherwise it will receive error, but only one is requested at the end.
Taking a look at the code, currently is a ResourceDefinitionGenerator's responsibility to decide to create or not the definition (in the ObjectStorage, PushStream, S3 there are checks into the generate method to verify the condition, otherwise they return null, instead in the HttpProviderProxy one nothing is checked).

Probably to improve readability and align it to the canHandle pattern used with provision, data flow controllers, ecc... I think a canHandle method on the ResourceDefinitionGenerator interface could avoid problems.

[jimmarino]

@ndr-brt Let's look at this post M3. I'm currently working on some other refactoring in this area. We can align it to use a "canHandle" ("applies" may be more appropriate name since multiple generators may be engaged) where the manifest generator compiles a collection of definition generators to run.