[
https://issues.apache.org/jira/browse/NIFI-10851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636910#comment-17636910
]
ASF subversion and git services commented on NIFI-10851:
--------------------------------------------------------
Commit 620b7365c2ed0bc741920d5208d733f540795b16 in nifi's branch
refs/heads/main from Paul Grey
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=620b7365c2 ]
NIFI-10851 Corrected removal of Controller Service references on property
updates
- Convert unit test to JUnit 5
This closes #6695
Signed-off-by: David Handermann <[email protected]>
> On update to controller service reference in processor configuration, ensure
> removal of old reference
> -----------------------------------------------------------------------------------------------------
>
> Key: NIFI-10851
> URL: https://issues.apache.org/jira/browse/NIFI-10851
> Project: Apache NiFi
> Issue Type: Bug
> Reporter: Paul Grey
> Assignee: Paul Grey
> Priority: Minor
> Fix For: 1.19.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> https://lists.apache.org/thread/jjjopqndrp9y6dzdnjxsdfhw2ofjh469
> {quote}I'm using NiFi 1.18.0, and I use the controller services configure,
> enable or disable screen, to determine what processors is using it. That way
> I can determine if I can delete the controller service or not. Or, if I have
> to migrate from 1 controller service to a controller service in a processor
> group. (For instance, my flow gets too big, so I move the processors to a
> group, but the controller services stay at the root level.) (That way I can
> know for sure a controller service can get deleted because nothing is using
> it, rather than deleting the controller service and having to find all
> processors after the fact that are now invalid because of that.)
> To test this, I was able to do the following. Create a processor group, add
> ConvertRecord in the group, and choose a standard AvroReader as the service
> at the root level. Name all of them for uniqueness. Copy the processor group,
> go into the ConvertRecord and choose a new processor group level AvroReader,
> and name these items uniquely as well. Go back to the root level and look at
> the root AvroReader, and it was showing both ConvertRecords, even the one in
> the copied group that has a new AvroReader in it.
> I just tried that test in a 1.9.0 NiFi instance, and it didn't have the same
> problem.{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
