[
https://issues.apache.org/jira/browse/PROTON-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653536#comment-14653536
]
ASF GitHub Bot commented on PROTON-964:
---------------------------------------
Github user bozzzzo commented on a diff in the pull request:
https://github.com/apache/qpid-proton/pull/48#discussion_r36181146
--- Diff:
proton-j/src/main/java/org/apache/qpid/proton/engine/impl/EventImpl.java ---
@@ -217,6 +101,19 @@ public void dispatch(Handler handler)
dispatch(children.next());
}
}
+
+ @Override
+ public void redispatch(EventType as_type, Handler handler) throws
HandlerException
--- End diff --
This is for now the only way to actually generate non-core, events...
I'll extend the javadoc to make it explicit. This was the minimal change
needed and right now behaves as you describe.
A typical example would be a message decoder handler that turns a DELIVERY
event into a MESSAGE event with attached message in the event. Or a timer for
periodic sampling of a Connection, and so on.
I'm in fact sitting on some more reactor/collector changes that were done
later and for other use cases. One of them is the ability for a handler to have
children process the event synchronously.
I can also fold the implementation of that change in here as it would then
allow redispatch() to have child handlers be invoked first with the original
event, before redispatching the new type.
And keep exposing the interface for that in a separate jira.
> Proton-J extensible event types
> -------------------------------
>
> Key: PROTON-964
> URL: https://issues.apache.org/jira/browse/PROTON-964
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
> Affects Versions: 0.10
> Reporter: Bozo Dragojevic
> Assignee: Bozo Dragojevic
> Fix For: 0.11
>
>
> Event.Type is an enum which makes it impossible to extend.
> Introduce a separate interface EventType and make Event.Type implement it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
