SEDA contribution from Mark Schier

[Berin Loritsch <bl...@apache.org>]

There are some things to like such as the removal of QueueElement as a
necesity.  I have removed that from the production version of Avalon,
as well as separated the implementation of the Queues and the
interfaces.

However, there are some things that I am curious as to your reasoning.
The version of SandStorm (the SEDA implementation that inspired
the event package) did not have EventHandlerExceptions, and I don't
think
that they belong.

An EventHandler will respond to events it knows how to handle, and
forward
on any events it does not know how to handle.  I think that is the best
way.  Throwing an exception means that the bad elements have to be
handled
by the container by either removing them, or moving them forward through
the system.  It is not the proper exception handling process for an
event
based system.

What should happen is the EventHandler/Stage should enqueue a Signal
that
the container can divert to the SignalHandler.  That way we can properly
log the event.  As it is now, we would loose information should the
EventHandler not properly process or forward the faulty elements before
it throws the exception.  That IMO is a bad thing.

Regarding the Stage Queue operations, I think we can clean things up.
If the Stage can get its Sink directly set by the container, we can set
up a multiplexing queue based on the type of element.  However, that
requires
the container to have intimate knowledge of the types that come out of
the Stage.  I don't think the Stage should want to enqueue things to
itself
again.  That might cause some other issues such as infinite loops that
are
hard to detect.  If we keep to the SinkMap format, we should keep it
simple.
The SinkMap would return the default Sink, and a small collection of
named
sinks.  That way the Stage can make intelligent decisions as to which
Sink
it forwards information to.


"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
                - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>