[
https://issues.apache.org/jira/browse/NIFI-5230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16487440#comment-16487440
]
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_r190286397
--- 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 , regarding Set vs List. Validation Result supposed to be
Collection, so technically - any of them can be used. But consistency should
come with Set, as if you check super class AbstractConfigurableComponent, its
customValidate returns:
return Collections.emptySet();
So, I would say, we need to refactor ArrayList into Set, but then there
will be more potential regression impact. I'd recommend to keep it as is for
this PR/Jira, and have another ticket opened on cosmetic improvement to change
ArrayList to to some Set implementation during initialization. I hope it makes
sense.
> 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)
