nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Bean <mark.o.b...@gmail.com>
Subject Re: Dynamic property for controller service
Date Thu, 09 Jan 2020 22:51:07 GMT
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 <mattyb149@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 <mark.o.bean@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message