[
https://issues.apache.org/jira/browse/GRIFFIN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633516#comment-16633516
]
Nikolay Sokolov commented on GRIFFIN-200:
-----------------------------------------
> One disadvantage of run time class loader reflection is that there will be
> some compile time dependencies between griffin and customers logic, which
> might inject some griffin agreements into customer's code, not acceptable for
> them.
Having hook as simple POJO would keep enough freedom for user to pick
acceptable solution, depending on situation and task complexity. From shading
and relocation of conflicting dependencies, to publishing to outside systems
over HTTP or any other protocol. Or if particular user would pick Spring
Integration as way to communicate with outside systems, respective
configurations would come as part of plugin jar.
> One proposal is spring integration model.
I'm not really an expert in Spring Integration, so let me see if I've
understood you right.
In case of Spring Integration, user would be defining Channels and Endpoints,
and Griffin would be sending messages to those Channels. Classpath conflicts
are resolved by using standard integration endpoints, such as HTTP or AMQP, and
actual reaction will happen outside of Griffin's JVM, on a side receiving
messages. However clients are not limited to standard endpoints and can place
their implementations directly into Griffin's classpath and handling messages
from channel directly.
Is this understanding correct?
> Lifecycle hooks support
> -----------------------
>
> Key: GRIFFIN-200
> URL: https://issues.apache.org/jira/browse/GRIFFIN-200
> Project: Griffin (Incubating)
> Issue Type: New Feature
> Reporter: Nikolay Sokolov
> Assignee: William Guo
> Priority: Minor
>
> In some environments, users might want to perform certain actions
> before/after job is created, before/after job is activated, before/after job
> is deleted, and so on.
> To fullfill that need, some hook plugin mechanism can be provided, similar to
> what Hive is doing. User would place respective jar files into Service module
> classpath at deployment time, and would specify class names using some
> annotation or using property listing class names (particular mechanism is yet
> to be determined).
> Proposed signature:
> {code:none}
> public interface JobLifecycleHook {
> void beforeAddJob(AbstractJob js) throws Exception;
> void afterAddJob(AbstractJob js) throws Exception;
> void beforeOnAction(AbstractJob job, String action) throws Exception;
> void afterOnAction(AbstractJob job, String action) throws Exception;
> void beforeDeleteJob(AbstractJob job) throws Exception;
> void afterDeleteJob(AbstractJob job) throws Exception;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
