Hi Michael, Generally processors are supposed to only know about an interface for the service, and then the framework makes the implementations of that interface available. So the processors shouldn't really know which specific implementations are available.
I think there are a couple of things that could be done... You can make a new interface called RestrictedSSLContextService that extends SSLContextService, and then have an implementation like StandardRestrictedSSLContextService... then make your customized ListenHTTP processor rely only on the new interface (RestrictedSSLContextService). Another option might be to do something involving custom validate (as you mentioned)... If the SSLContextService interface had a method to return a list/array of the supported protocols, then a processor could use those values in a custom validate to make sure that a service with the required protocols was selected. You are right that they would still see all the services in the drop-down, but the processor would be invalid and unable to be started until selecting the appropriate service, and they'd see the validation message about what was wrong. A final option, although not something that is currently possible, might be to leverage the security model... If you could restrict who could create a specific type of component, meaning something like "admin has create permissions on StandardSSLContext from nifi-standard-nar", then you could set it up so that regular users can create your restricted service and only admins (or maybe no one) can create the other kind. -Bryan On Mon, Aug 14, 2017 at 11:35 AM, Michael Hogue <[email protected]> wrote: > All, > > 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. > > Thanks, > Mike > > [1] https://github.com/apache/nifi/pull/1986
