[
https://issues.apache.org/jira/browse/NIFI-4149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16084405#comment-16084405
]
Joey Frazee commented on NIFI-4149:
-----------------------------------
It'd definitely be useful to enable EL on any property by default with the
assumption/clear indication that what it's eval'ing is java properties,
variable registry properties or the environment. Are there any circumstances
where you'd want to prohibit EL from these sources? I can't think of any
(assuming NIFI-2767 never goes in).
So the important thing then is how to clearly indicate the behavior in the UI
for the user and walk back all the supportsExpressionLanguage() methods on the
builders. For the former, I assume it'd be a tooltip update. For the latter, we
could either say no harm, no foul or deprecate the existing method and add
something like supportsFlowFileExpressions() so people will go clean stuff up.
Since I mentioned NIFI-2767, I'll add that the observation's been made that
what counts as a valid attribute expression is also entangled with the
processor lifecycle. So a more general solution would include a way to indicate
at what parts of the lifecycle the expressions can be evaluated against which
sources.
> Indicate if EL is evaluated against FFs or not
> ----------------------------------------------
>
> Key: NIFI-4149
> URL: https://issues.apache.org/jira/browse/NIFI-4149
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Reporter: Pierre Villard
>
> With the addition of EL in a lot of places to improve SDLC and workflow
> staging, it becomes important to indicate to users if the expression language
> enabled on a property will be evaluated against the attributes of incoming
> flow files or if it will only be evaluated against various variable stores
> (env variables, variable registry, etc).
> Actually, the expression language (without evaluation against flow files)
> could be allowed on any property by default, and evaluation against flow
> files would be what is actually indicated in the UI as we are doing today.
> Adopting this approach could solve a lot of JIRA/PRs we are seeing to add EL
> on some specific properties (without evaluation against FFs).
> Having expression language to access external values could make sense on any
> property for any user. However evaluating the expression language against FFs
> is clearly a more complex challenge when it comes to session management and
> such.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
