For the specific case of "host name of the AMQP processors", EL support for that property was added to NiFi in NIFI-5489 [1] which will be released with NiFi 1.8.0 (available real soon!)
[1] - https://issues.apache.org/jira/browse/NIFI-5489 -- Mike On Wed, Oct 24, 2018 at 3:06 PM Pierre Villard <[email protected]> wrote: > Hi there, > > There is a JIRA [1] about this idea and, as Joe said, we need to carefully > think about the implications. Unless we can do something nice and backward > compatible, that could be something for NiFi 2.0. > > [1] https://issues.apache.org/jira/browse/NIFI-5367 > > Pierre > > Le mer. 24 oct. 2018 à 20:59, Joe Witt <[email protected]> a écrit : > > > Jon, > > > > There is very little overhead really. The answer more generally has > > to do with history. Expression language was added later in the game > > and there can be different scopes to what a given EL statement has > > access to. Some EL are evaluated against flowfiles and some arent. > > We didn't have a good way to show users this information though this > > has recently improved. It also has to do with 'evaluation time' > > meaning processors might evaluate some properties frequently/while > > executing a task (as would be the case when EL statements have a given > > flowfile in scope) or during enabling/scheduling such as pulling a > > property value they intend to honor throughout an entire runtime. > > > > I suspect at this point that we can make most properties (not > > enumerations most likely) EL enabled. But, each one requires > > review/consideration to ensure the processor is coded to use it > > correctly. > > > > Alternatively, we could explore making all text entry fields allow > > users to explicitly state 'this is a variable and here is the variable > > name' (but in a cool UI way) and then the actual value used would come > > from the variable registry for that process group. This would be > > something we can do across the board as it wouldnt' change the > > processor's logic/behavior at all. Variables get set at and retained > > throughout the life of a processor run. If a used variable is changed > > we'd automatically stop/start each impacted component/processor so it > > wouldnt' require any additional review/changes in processor > > properties. > > > > ThanksOn Wed, Oct 24, 2018 at 2:46 PM Jonathan Meran > > <[email protected]> wrote: > > > > > > Hello there, > > > Regarding expression language properties, why aren't all or most > > properties enabled by default. > > > > > > Is there substantial processor overhead on these? > > > > > > Thanks, > > > Jon > > > > > > On 10/24/18, 1:49 PM, "Joe Witt" <[email protected]> wrote: > > > > > > Mark > > > > > > There are two scenarios here to discuss: > > > 1) What do to with sensitive properties > > > 2) What to do with properties that dont allow expression language > > statements > > > > > > For #1 we dont send those properties into the registry and they are > > > set (properly) in each environment where the secret belongs. All > > good > > > as that doesn't change the flow definition. > > > > > > For #2 we should just look at which properties are causing trouble > > and > > > see about expression language enabling them. So please share > > > precisely which ones you're hitting where that would help you out > and > > > lets see what can be done. > > > > > > Thanks > > > On Wed, Oct 24, 2018 at 1:39 PM Mark Littleton > > > <[email protected]> wrote: > > > > > > > > Hi Everyone, > > > > > > > > I'm currently doing a lot of work with Nifi and recently we have > > been trying to come up with a solution to a problem. We installed Nifi > > registry backed by our Git repository for versioning our flows. This has > > worked out great for us as we can now track the version of our flows > > correctly and make sure they are backed up in source control. > > > > > > > > However when we want to do deployment between our Development > Nifi > > cluster and our Qa Nifi cluster we have to ofcourse change some values. > > These could be amqp queues, directories on the file system etc. > > > > > > > > So ofcourse we use variables so that we can configure the values > > without it being detected as a change to the flow. A problem arises > however > > when we need to configure an option that does not support expression > > language. For example the host name of the amqp processors. > > > > > > > > This leaves us in a situation where a change to the flow is > > detected. The only real option I have as far as I can see is to clone the > > flows and have one for each environment which I don't like at all. > > > > > > > > Is anyone else struggling with similar issues. If so how are you > > handling It? > > > > > > > > Sent from my Sony Xperia™ smartphone > > > > > > > > >
