exceptionfactory commented on PR #9685: URL: https://github.com/apache/nifi/pull/9685#issuecomment-2638161663
> I could add an additional state if this use case is strongly desired. But I won't spend the cycles if it is still going to receive a "-1". Yes, it doesn't sound like making further changes at the point would be worth pursuing. > > The original use case - which is still a powerful one that has been requested for years - is to use this rule as a mechanism to locate all load balanced connections. Currently, there is no way to do that short of manually parsing the flow.json.gz file. For this reason alone, I find this Flow Analysis Rule a significant improvement. For this reason alone, I find it unreasonable to reject even if not yet a perfect solution (with many of the arguments against being within framework, not the rule.) Thanks for focusing the goal of the current rule. The purpose of Flow Analysis Rules should not be finding component configuration properties, but finding settings that are not aligned with flow design requirements or recommendations. As an extension point, the Rule API can be used for any number of things, so as a custom implementation, this rule may meet that need. However, as a way to fill a gap in functionality, this approach seems to go outside the general purpose of Flow Analysis Rules. For these reasons, it does not appear to be a good fit for inclusion in the standard set of rules. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
