You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Mark Bean <ma...@gmail.com> on 2020/01/09 22:01:00 UTC
Dynamic property for controller service
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
Re: Dynamic property for controller service
Posted by Mark Bean <ma...@gmail.com>.
The PR solution is slightly different from mine. It short-circuits the
validation immediately if the required API is the generic
"ControllerService" interface. I suppose that's better to put up front
rather than run through the whole chain only to reach the "special case" at
the end.
This solution should work in my use case.
Thanks!
On Thu, Jan 9, 2020 at 5:26 PM Matt Burgess <ma...@apache.org> wrote:
> 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 <ma...@gmail.com> 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
>
Re: Dynamic property for controller service
Posted by Matt Burgess <ma...@apache.org>.
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 <ma...@gmail.com> 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