nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hogue <>
Subject Restricting Controller Service Class Definitions
Date Mon, 14 Aug 2017 15:35:44 GMT

   I'm in the process of making some changes to a processor which exposes a
controller service with several implementations. However, I only want to
allow a particular implementation for the processor, but i've not found a
clean way to do this. The rationale behind wanting to do this can be found
in the conversation on PR #1986 [1]. In short, I've written a
RestrictedSSLContextService that allows only a specific set of SSL
algorithms to be chosen. I want to change ListenHTTP to allow only that
implementation and not the StandardSSLContextService.

   PropertyDescriptor builders have a method
identifiesControllerService(clazz) which allows you to dictate which
interface the controller service must implement. This is great because it
should allow me to specify an explicit implementation i'd like to force the
processor to allow. The problem with this is that it necessitates an
additional dependency on a non-API module, which i believe is ill-advised.
It actually results in multiple identical controller service entries when
you go to configure the controller service in the UI due to nar service
loading. This is probably a bad thing.

   I've looked across the code base and don't really see an example of
restricting controller service options to specific implementations if you
only want to allow a subset, for example. Adding a validator wouldn't
really work either since the UI would still allow you to choose a
controller service you don't want to allow. My question to those more
familiar with the codebase is whether there's an obvious way to approach
this or if there needs to be significant changes to allow it.



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