[
https://issues.apache.org/jira/browse/NIFIREG-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574916#comment-16574916
]
ASF GitHub Bot commented on NIFIREG-190:
----------------------------------------
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).
> Support for Event Whitelisting in the Registry Event Hooks
> ----------------------------------------------------------
>
> Key: NIFIREG-190
> URL: https://issues.apache.org/jira/browse/NIFIREG-190
> Project: NiFi Registry
> Issue Type: New Feature
> Affects Versions: 0.2.0
> Reporter: Jeremy Dyer
> Assignee: Jeremy Dyer
> Priority: Major
> Fix For: 0.3.0
>
>
> Today when an event hook is configured it will be invoked for all of the NiFi
> Registry events. While a user can parse the arguments in the script and
> manually write scripts which ignore certain events it makes more sense to
> provide this event whitelisting the the registry itself.
> I propose adding a new property called something like "Event Whitelist" to
> the current configuration logic. If this property is not present things
> should continue to operate just as they do now, AKA the script is sent all of
> the events, if the property is specified it should contain a comma delimited
> list of events that the hook provider should be triggered for.
> This will be extremely useful when providers that do not provider any sort of
> filtering logic like the script hook provider come along.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
