Mark, Good timing; Shawn, Bryan and I were talking about that on the Apache NiFi Slack just today. It's been captured in NIFI-6852 [1] and Shawn has drafted a PR [2] and is working on a unit test for it. My overall thought is that you really shouldn't be binding to the generic ControllerService, rather an interface that extends from it, for the purposes of filtering on a particular type of ControllerService. But for scripted (and some custom) components, you may need to allow that kind of flexibility, so we should probably support validation (or lack thereof as it were) in those cases, and that's what the Jira is about.
For ExecuteGroovyScript, the CTL "object" is apparently very helpful, and it sounds like you're doing something similar in your custom CS. However even after [1] is resolved, I will likely go into ExecuteGroovyScript and add objects for common controller services such as RecordReader/Writer. Using specific CS interfaces helps because you can use a dropdown to select the instances, rather than the boilerplate code of getting the ControllerServiceLookup and looking up by name/ID. You may want to look at doing the same for your custom CS if you know the subset of controller service interfaces you want to support. Regards, Matt [1] https://issues.apache.org/jira/browse/NIFI-6852 [2] https://github.com/apache/nifi/pull/3973/files On Thu, Jan 9, 2020 at 5:01 PM Mark Bean <[email protected]> wrote: > > I have a custom controller service with dynamic properties. The dynamic > property value is expected to be a controller service. Therefore, the > getSupportedDynamicPropertyDescriptor returns a PropertyDescriptor from the > Builder with "identifiesControllerService(ControllerService.class)". This > is because the property could be any controller service. > > During validation (in AbstractComponentNode), the actual controller service > specified is compared with the expected API (i.e. ControllerService.) But, > the API coordinate is "default:system:unversioned". > > First, is this correct? Why wouldn't ControllerService have a coordinate of > 1.10.0 and whatever NAR it lives in? > > Second, if the above is correct, what would you recommend for validating > the custom controller service? > > I thought about adding an allowance in > AbstractComponentNode.validateControllerServiceApi such that if all other > API checks fail AND the provided descriptor is dynamic AND the API > coordinate is "default:system:unversioned", then the validation result is > valid. This catchall seems a little open-ended though. > > Suggestions? > > Thanks, > Mark
