Mailing-List: contact issues-help@nifi.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@nifi.apache.org
Date: Sun, 24 Sep 2017 23:46:01 +0000 (UTC)
From: "Joseph Percivall (JIRA)" <jira@apache.org>
To: issues@nifi.apache.org
Message-ID: <JIRA.13104623.1506296479000.188576.1506296761878@Atlassian.JIRA>
In-Reply-To: <JIRA.13104623.1506296479000@Atlassian.JIRA>
References: <JIRA.13104623.1506296479000@Atlassian.JIRA> <JIRA.13104623.1506296479997@jira-lw-us.apache.org>
Subject: [jira] [Resolved] (NIFI-4415) Processors should be explicit in what
 is evaluated for a property that supports Expression Language
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sun, 24 Sep 2017 23:46:10 -0000


     [ https://issues.apache.org/jira/browse/NIFI-4415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joseph Percivall resolved NIFI-4415.
------------------------------------
    Resolution: Duplicate

Apparently, I've already raised this issue in the past and my search skills didn't quite make find it before creating this one.

Closing this one in favor of the other since it is older.

> Processors should be explicit in what is evaluated for a property that supports Expression Language
> ---------------------------------------------------------------------------------------------------
>
>                 Key: NIFI-4415
>                 URL: https://issues.apache.org/jira/browse/NIFI-4415
>             Project: Apache NiFi
>          Issue Type: Improvement
>            Reporter: Joseph Percivall
>
> Currently, when a processor evaluates an Expression Language (EL) expression, it can do so by providing multiple different inputs to the function[1]. Without looking at the code and not explicitly stated in the docs, the user does not know what is available for them to use. 
> The list of available options to pass to evaluate includes:
> * A FlowFile
> * An attribute value decorator
> * Any state values
> * Any additional attributes that may be processor specific
> At worst, a user will attempt design a flow thinking a processor's EL supports passing values via attributes and coming to find that it doesn't allow access to the FlowFile through an obscure error. At "best", a user just doesn't know about a certain functionality.
> One may ask why a processor wouldn't allow access to the values. At the most basic, the processor may just not make use of that feature (a processor not storing state). On the other end, a processor may not expose access to a FlowFile's attributes because the evaluation happens once per scheduling (when there isn't a FlowFile) or once per batch (eg. PutElasticsearchHttp's url[2])
> A developer should be able to state what will be evaluated in the same place that they originally indicate that a property supports EL. NiFi should then pass that information to the user of the processor via the documentation (in the same way it tells the user whether EL is supported or not).
> [1] https://github.com/apache/nifi/blob/50ea1083ec416c5d6e70c4e7bb5b2abde8f6266c/nifi-api/src/main/java/org/apache/nifi/components/PropertyValue.java#L139
> [2] https://github.com/apache/nifi/blob/4e4d14f86ff21d2c7d20d9e180acee54a2ddf93b/nifi-nar-bundles/nifi-elasticsearch-bundle/nifi-elasticsearch-processors/src/main/java/org/apache/nifi/processors/elasticsearch/PutElasticsearchHttp.java#L225


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)