commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jung, Eric" <>
Subject RE: sandbox proposal. Events
Date Mon, 04 Oct 2004 17:23:53 GMT
I use an "event handler chain" (my term for the pattern you describe) in an
application right now that requires the handler(s) which failed be
identified after the event handler chain completes. [The chain may or may
not continue processing if one handler fails]. The best way I thought to do
this was to use an array of return values. Order is derived via the means
you describe below (element indices coupled with a return value from the
"register delegate" method). However, a more general approach might be to
return a hash from the "register delegate" method and use a Map of return
values, instead of an array or list.

My two cents,
Eric Jung

-----Original Message-----
From: Mike Stanley [] 
Sent: Monday, October 04, 2004 1:05 PM
To: Jakarta Commons Developers List
Subject: RE: sandbox proposal. Events

On Mon, 2004-10-04 at 12:42, Jung, Eric wrote:

> >If the delegate methods return a value,
> >the last value would be returned (this is the
> > behavior of the .NET approach.  I'm open to other suggestions).
> How about the option of either (1) receiveing the last value or (2)
> receiving an array of values, where each array element represents a return
> value?

It currently returns the last value.  The problem with returning an
array of values is the problem with matching up methods to return
values.  Since order is retained this can be done by keeping track of
when something was added (return index on registration to ensure
syncrhonized index etc.)  I didn't add this though because (1) at the
time I wrote it I didn't need this capability and (2) I questioned if I
ever would need this.

if other's can think of a situation that calls for (2), I'm thinking the
best way to handle it would be to return an EventResult.  That allowed
you to obtain return values / stack traces, and other invocation info 
for each method based on the registration index of the method.

- Mike

> -----Original Message-----
> From: Craig McClanahan [] 
> Sent: Monday, October 04, 2004 12:39 PM
> To: Jakarta Commons Developers List;
> Subject: Re: sandbox proposal. Events
> Mike,
> This pattern does indeed sound interesting.  You might also want to
> take a look at the [pipeline] sandbox package (contributed by Kris
> Nuttycombe) that I checked in over the weekend.  It offers a different
> tack on handling asynchronous events, and is also investigating how an
> interaction with [chain] might be beneficial.
> >From a practical perspective, there exists already a sandbox package
> named [events], originally extracted from [collections].  I haven't
> been tracking whether this is actually active or not; if so, we'd need
> to use some different top level name for the package itself.
> Craig
> On Mon, 04 Oct 2004 11:19:15 -0400, Mike Stanley <>
> wrote:
> > I've implemented a pattern, somewhat based off the .NET event and
> > delegate pattern, however the pattern is also commonly seen in
> > frameworks (to some extent).
> > 
> > At a high level, the pattern is made up of two objects:
> > - Event
> > - DelegateMethod
> > 
> > The Event is a container for DelegateMethods.  Delegate Methods are
> > registered with the Event (added to the container).  The first delegate
> > method added to the container determines the contract for that event.
> > I.e. each method added must have similar signatures (take the same
> > number and types of parameters and return the same type).  At any time
> > the event can be fired.  When an event is fired it invokes the delegate
> > methods in the order they were added.  The event can be configured to
> > fail on first exception, or continue without failing.  If the delegate
> > methods return a value, the last value would be returned (this is the
> > behavior of the .NET approach.  I'm open to other suggestions).
> > 
> > A Delegate Method gets created with an instance of an object and the
> > name of the method (optionally when instantiating the Delegate Method
> > you may specify the signature - or actual Method, in the case that there
> > are multiple methods with the same name but different signatures).  This
> > method will be invoked using reflection (delegateMethod.invoke(args))
> > when the event is fired.
> > 
> > At it's core this is the basic idea.  Above this, there are (*plans*) to
> > create Asynchronous Delegate Methods and events, providing simple
> > support for multi-threaded events.  This will use the same concepts from
> > .NET (callbacks, begin invokes, end invokes, async results, etc).
> > 
> > I'm also investigating migrating the pattern to utilize "commons-chain".
> > 
> > Currently this does not exist as a stand-alone library.  However, if
> > there is interest, I will begin to pull it out and contribute it to the
> > commons-sandbox.
> > 
> > - Mike
> > 
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message