Github user pvillard31 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2160#discussion_r140331750
--- Diff:
nifi-nar-bundles/nifi-kudu-bundle/nifi-kudu-processors/src/main/java/org/apache/nifi/processors/kudu/AbstractKudu.java
---
@@ -124,11 +148,14 @@ public void OnScheduled(final ProcessContext context)
{
kuduTable = this.getKuduTable(kuduClient, tableName);
getLogger().debug("Kudu connection successfully
initialized");
}
+
--- End diff --
I would add
````java
.expressionLanguageSupported(true)
````
To table name, Kudu masters, and batch size properties.
Then, when you retrieve the value you add
``.evaluateAttributeExpressions()`` before ``getValue`` or ``asInteger``.
Example:
````java
tableName =
context.getProperty(TABLE_NAME).evaluateAttributeExpressions().getValue();
````
This way a user can use expression language in the property value to
reference externalized variables: in the variable registry, environment
variables, etc. It's particularly useful when you're moving a workflow from a
development environment to a production environment: you can set your table
name in a variable "myTable" and this way you have the same workflow in both
environments. It's just a matter of setting a different value for this variable
(it's easier than modifying a workflow). And if you have multiple instances of
the processors you can update all the processors by changing the value in one
place only.
TBH expression language should be enabled on almost all the properties as
it's really helping the continuous deployment process.
---
