I get your point.
It's possible to add a logger filter more than once in the chain, assuming
the name is not the same. I would argue that for any event to start at the
Head in order for it to traverse all the filter is a bit spurious: such
event is likely not to be process by any filter.
I'll see if adding a fireEvent() method in the head filter is not more
'consistent' with what we currently have for other events, and rename
'fire' to 'event'.
On Fri, Apr 13, 2018 at 6:25 PM, Emmanuel Lécharny <elecha...@gmail.com>
> Sent to the dev list, where it belongs...
> -------- Message transféré --------
> Subject: Re: Adding a secured() event in the IoHandler
> To: Emmanuel Lécharny <elecha...@gmail.com>
> If nextFilter.fire is called within messageReceived then it will send the
> event to SSL Filter + 1; if nextFilter.fire is called within messageSent
> then it will send the event to SSL Filter -1; Forcing it to start at the
> head would make it more uniform and allow for debugging filter to be ahead
> of the SSL Filter. Not really a big deal.
> On Fri, Apr 13, 2018 at 10:52 AM, Emmanuel Lécharny <elecha...@gmail.com>
> > Le 13/04/2018 à 16:32, Jonathan Valliere a écrit :
> > > Couple of comments:
> > >
> > >
> > > 1. Any specific reason why you chose “fire” for the base name of the
> > > handler function instead of something like “event” ?
> > No. It could be named event if it makes more sense.
> > > 2. Instead of calling nextFilter.fire; you might want to call
> > > session.getFilterChain().fire() or
> > > session.getFilterChain().getEntry(this).fire() force correct
> > > behavior regardless of current processing direction.
> > I don't think it makes any sense to propagate an event back to the head.
> > The only place processing events is the IoHandler, which is the next
> > after the tail.
> > --
> > Emmanuel Lecharny
> > Symas.com
> > directory.apache.org