NIFI-16373 - adding ResourceType for FetchFile FILENAME property

[iadamcsik]

Summary

NIFI-16373 Since the processor has a not.found relationship, adding FILE type only would render that unusable, hence adding both FILE and TEXT type.

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000
• Pull request contains commits signed with a registered key indicating Verified status

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using ./mvnw clean install -P contrib-check
  • JDK 21
  • JDK 25

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[exceptionfactory]

Thanks for proposing this change @iadamcsik. However, just adding this identifiesExternalResource() designation is not sufficient. The class implementation always uses this as a File path, making TEXT and invalid value based on the implementation

[exceptionfactory]

The Jira issue is lacking additional details, so if could describe the intended behavior, that would help narrow down the correct direction

[iadamcsik]

@exceptionfactory Expended a bit on the ticket.

just adding this identifiesExternalResource() designation is not sufficient.

Do you mean that regarding providing the TEXT type as well to the builder? I only added that as means to preserve the functionality of the not.found relationship. With only FILE added, the validator prevents the processor from running if the file is missing. So there is no intention of adding free text support to this processor.

The goal is to have the FILE type generated into the manifest so third-party integrations can be aware of the actual type of the property.

[exceptionfactory]

@exceptionfactory Expended a bit on the ticket.

just adding this identifiesExternalResource() designation is not sufficient.

Do you mean that regarding providing the TEXT type as well to the builder? I only added that as means to preserve the functionality of the not.found relationship. With only FILE added, the validator prevents the processor from running if the file is missing. So there is no intention of adding free text support to this processor.

The goal is to have the FILE type generated into the manifest so third-party integrations can be aware of the actual type of the property.

If TEXT is added, then the implementation needs to change to read the text content, but I agree that should not change given the nature of the Processor itself.

There are other components that use just FILE, do you have an example of where that fails with only that addition?

[iadamcsik]

Nothing fails per se, but since the validation stops the processor from running, the not.found relationship would become moot.
E.g.:

[exceptionfactory]

Nothing fails per se, but since the validation stops the processor from running, the not.found relationship would become moot. E.g.:

Can you share the configuration of that property? If it is using Expression Language, per the default value, then the validation should pass, and the not.found relationship would apply when dynamically resolving the value for each input FlowFile.

[iadamcsik]

I didn't use EL in the above example, but I did try it out and the validation still failed:

[exceptionfactory]

I didn't use EL in the above example, but I did try it out and the validation still failed:

Thanks, #{path} is a Parameter value reference, not an Expression Language value, so I would expect validation issues. Did you try the default value of the property?

[iadamcsik]

Right, sorry, jumped to gun on that one. Using EL did produce the expected outcome. Removed TEXT type.