[
https://issues.apache.org/jira/browse/NIFI-5230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16487422#comment-16487422
]
ASF GitHub Bot commented on NIFI-5230:
--------------------------------------
Github user bdesert commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2734#discussion_r190283975
--- Diff:
nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/main/java/org/apache/nifi/processors/script/InvokeScriptedProcessor.java
---
@@ -237,7 +237,7 @@ public void setup() {
@Override
public void onPropertyModified(final PropertyDescriptor descriptor,
final String oldValue, final String newValue) {
--- End diff --
@ottobackwards , when a processor is invalid (customValidate returned
validation errors), we keep all the validationResults. Method 'customValidate'
just check if there are already errors - no need to validate again, just return
whatever is stored.
When any property is getting modified - these validation results may not be
accurate anymore, so we have to reset them. Once reset (onPropertyModified),
next call to customValidate will run full validation and set new errors if
found. So at any point we don't drop validation results for no reason. Am I
missing anything?
> InvokeScriptedProcessor can issue a NullPointerException in customValidate
> --------------------------------------------------------------------------
>
> Key: NIFI-5230
> URL: https://issues.apache.org/jira/browse/NIFI-5230
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.6.0
> Reporter: Matt Burgess
> Assignee: Matt Burgess
> Priority: Major
> Fix For: 1.7.0
>
>
> NIFI-4968 improved the behavior of InvokeScriptedProcessor when the script
> has an error during parsing/interpretation/compilation, and an improvement
> was made to not output the same validation errors over and over again until
> manual action was taken. As part of that improvement though, a bug was
> introduced where a NullPointerException can occur.
> Proposed fix is not to set the validation results to null on "clear", but
> rather to an empty Set (which the code is expecting)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
