Github user kevdoran commented on the issue:
https://github.com/apache/nifi-registry/pull/133
If we are allowing each implementation to decide the logic in the handle
method, I don't see the value in the "share property" concept as documented:
> There are certain properties that are shared amongst all of the NiFi
Registry provided Event Hook implementations.
I don't think we should introduce the concept of a shared property that is
documented as being honored by all implementations when we really have no way
to guarantee that.
In this PR, the implementation that does handle the Event Whitelist is
implemented as an Abstract base class in the framework, which would make it
difficult for third-party extension providers to implement (or they could
ignore it if they want as it is not part of the API).
If we want to make it universal, I think we would need to introduce a
dedicated field for whitelist that is enforced by the framework code (perhaps
using a decorator / wrapper), not the extension. Otherwise, don't think we make
it universal at all, it can just be an optional thing that third parties can
choose to implement.
One way to make it more obvious to custom implementations that this is
intended to be implemented would be to make it part of the interface they have
to implement (otherwise it is just documentation and hard to enforce). For
example, we could add a new method with a default implementation to the
`EventHookProvider` interface. For example:
```
default boolean shouldHandle(EventType eventType) {
return true;
}
```
If it's not overridden with a custom implementation, the event hook
provider will always be called. If it is overridden, they can return a boolean
for the event types they are interested in, either as a hard-coded set or a
user-configurable set (they would still need to document their own
configuration property for that).
---
