tree 7001dfd6b3f7ebf5f6c656a86eecbf62a2767614
parent ee9eb5b59fbce645cf5c24b927a60f70d1014a96
author Jacek Centkowski <jcentkowski@collab.net> 1504883847 +0200
committer Jacek Centkowski <jcentkowski@collab.net> 1508325621 +0200

Introduce events processor

Current webhooks implementation supports stream-events like (native)
events. However, enabling implementation of different formats may be
useful.

The following steps were performed to enable it:
* Configuration was changed to be extensible (this way adding more
configuration options is achievable by injecting specific
implementation)

* EventProcessor interface was introduced and it is responsible for
handling event according to provided remote configuration.

* EventProcessor's process method is performed by executor in dedicated
thread hence it could be resource consuming. In addition result of
processing is kept in Supplier with cache (memoize) so that processing
is not repeated when post gets repeated (for recoverable failure).

* Default implementation is provided and injected within ProcessorModule
that could be overwritten with different implementations without
necessity to re-bind core webhook classes (HttpSession,
HttpResponseHandler, etc) so that they can stay package-protected.

4 steps to introduce own webhook implementation and preserve plugin's
logic for HTTP and configuration handling:
1. implement EventProcessor or better AbstractEventProcessor as it
already checks if event is configured for remote
2. extend Configuration and inject it directly in case more
configuration options are required by implementation
3. extend ProcessorModule to bind EventProcessor to its new
implementation
4. add bindings for Configuration and ProcessorModule implementations
and install Module so that all necessary bits (related to webhooks
configuration and HTTP handling) are provided by Guice

Change-Id: Id575eba9b5aedd917e2441a70ae87d43276d2ab1
Signed-off-by: Jacek Centkowski <jcentkowski@collab.net>