[
https://issues.apache.org/jira/browse/NIFI-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16498227#comment-16498227
]
ASF GitHub Bot commented on NIFI-5145:
--------------------------------------
Github user MikeThomsen commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2749#discussion_r192455843
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ListFileTransfer.java
---
@@ -43,7 +43,7 @@
.description("The fully qualified hostname or IP address of the
remote system")
.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
.required(true)
-
.expressionLanguageSupported(ExpressionLanguageScope.VARIABLE_REGISTRY)
+
.expressionLanguageSupported(ExpressionLanguageScope.FLOWFILE_ATTRIBUTES)
--- End diff --
I spent some time trying to untangle it and found that the reuse of some of
these property descriptors between the FTP processors, combine with the
processors having different input requirements wrecked havoc on the test
framework. So I think we're going to need to commit the bare minimum fix here
and do a separate ticket to refactor the FTP processors.
> MockPropertyValue.evaluateExpressionLanguage(FlowFile) cannot handle null
> inputs
> --------------------------------------------------------------------------------
>
> Key: NIFI-5145
> URL: https://issues.apache.org/jira/browse/NIFI-5145
> Project: Apache NiFi
> Issue Type: Bug
> Reporter: Mike Thomsen
> Assignee: Mike Thomsen
> Priority: Major
> Fix For: 1.7.0
>
>
> The method mentioned in the title line cannot handle null inputs, even though
> the main NiFi execution classes can handle that scenario. This forces hack to
> pass testing with nulls that looks like this:
> String val = flowFile != null ?
> context.getProperty(PROP).evaluateExpressionLanguage(flowfile).getValue() :
> context.getProperty(PROP).evaluateExpressionLanguage(new
> HashMap()).getValue();
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
