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'. Thanks ! On Fri, Apr 13, 2018 at 6:25 PM, Emmanuel Lécharny <elecha...@gmail.com> wrote: > 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> > wrote: > > > > > > > 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 > downward > > > 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 > > > > > > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
