[
https://issues.apache.org/jira/browse/NIFI-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergei Zhirikov updated NIFI-6058:
----------------------------------
Description:
MockPropertyValue.getValue() (and other methods of the same family) will throw
an IllegalStateException when called on an object that wasn't returned from
evaluateAttributeExpressions(). It does that whenever the property in question
supports expression language (that is when expectExpressions is true). That
kind of logic is too strict. It would make sense to throw an exception only
when the value of the property actually contains something to be evaluated, in
other words, when isExpressionLanguagePresent() would return true.
Rationale: a processor could contain the following code, or something similar:
PropertyValue pv = processContext.getProperty(propertyDescriptor);
if (pv.isSet() && pv.isExpressionLanguagePresent())
pv = pv.evaluateAttributeExpressions(flowFile);
String value = pv.getValue();
This is a valid thing to do, and it works fine in real NiFi, but fails in tests
with nifi-mock. Unfortunately, calling
testRunner.setValidateExpressionUsage(false) does not help, because then
isExpressionLanguagePresent() will always return false.
Note: I have only tested this with 1.8.0, but the relevant code in the master
branch is the same, so I assume the issue applies to the latest version as well.
was:
MockPropertyValue.getValue() (and other methods of the same family) will throw
an IllegalStateException when called on an object that wasn't returned from
evaluateAttributeExpressions(). It does that whenever the property in question
supports expression language (that is when expectExpressions is true). That
kind of logic is too strict. It makes sense to throw an exception only when the
value of the property actually contains something to be evaluated, in other
words, when isExpressionLanguagePresent() would return true.
Rationale: a processor could contain the following code, or something similar:
PropertyValue pv = processContext.getProperty(propertyDescriptor);
if (pv.isSet() && pv.isExpressionLanguagePresent())
pv = pv.evaluateAttributeExpressions(flowFile);
String value = pv.getValue();
This is a valid thing to do, and it works fine in real NiFi, but fails in tests
with nifi-mock. Unfortunately, calling
testRunner.setValidateExpressionUsage(false) does not help, because then
isExpressionLanguagePresent() will always return false.
Note: I have only tested this with 1.8.0, but the relevant code in the master
branch is the same, so I assume the issue applies to the latest version as well.
> MockPropertyValue is overzealous about checking for expression evaluation
> -------------------------------------------------------------------------
>
> Key: NIFI-6058
> URL: https://issues.apache.org/jira/browse/NIFI-6058
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.8.0, 1.9.0
> Reporter: Sergei Zhirikov
> Priority: Minor
>
> MockPropertyValue.getValue() (and other methods of the same family) will
> throw an IllegalStateException when called on an object that wasn't returned
> from evaluateAttributeExpressions(). It does that whenever the property in
> question supports expression language (that is when expectExpressions is
> true). That kind of logic is too strict. It would make sense to throw an
> exception only when the value of the property actually contains something to
> be evaluated, in other words, when isExpressionLanguagePresent() would return
> true.
> Rationale: a processor could contain the following code, or something
> similar:
> PropertyValue pv = processContext.getProperty(propertyDescriptor);
> if (pv.isSet() && pv.isExpressionLanguagePresent())
> pv = pv.evaluateAttributeExpressions(flowFile);
> String value = pv.getValue();
> This is a valid thing to do, and it works fine in real NiFi, but fails in
> tests with nifi-mock. Unfortunately, calling
> testRunner.setValidateExpressionUsage(false) does not help, because then
> isExpressionLanguagePresent() will always return false.
> Note: I have only tested this with 1.8.0, but the relevant code in the master
> branch is the same, so I assume the issue applies to the latest version as
> well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
