You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by mattyb149 <gi...@git.apache.org> on 2018/06/01 14:11:45 UTC

[GitHub] nifi pull request #2749: NIFI-5145 Fixed evaluateAttributeExpressions in moc...

Github user mattyb149 commented on a diff in the pull request:

    https://github.com/apache/nifi/pull/2749#discussion_r192408467
  
    --- 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 --
    
    According to [this](https://github.com/apache/nifi/pull/2749/files#diff-a68a345757d54ad30f79658062d6e794R76), the attributes will not be populated with the right information if the attributes come in from flow files as no FlowFile is passed in. 
    
    This is a weird thing because ListFTP declares a property HOSTNAME that had EL scope VARIABLE_REGISTRY. But it also creates an FTPTransfer object which declares a HOSTNAME property that has EL scope FLOWFILES. Because they have the same name, the context fetches the FTPTransfer property but gets ListFTP's property instead. Then it calls evaluateAttributeExpressions(flowFile), but that violates ListFTP's HOSTNAME EL scope.
    
    This fix prevents the violation, but the attributes would still be incorrect right? I mention that because I thought of applying this same fix but instead put in the one from #2717 


---