Ok, I changed the Filter to get teh event go through the whole filter chain :
// Inform that the session is not any more secured session.getFilterChain().fireEvent(SslEvent.UNSECURED); So now, every filters that implement the event(FilterEvent) method will be able to see the propagated event. That's probably what you suggested, Jonathan. Le 14/04/2018 à 04:21, Emmanuel Lecharny a écrit : > 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 >>> >>> >> >> > > -- Emmanuel Lecharny Symas.com directory.apache.org
pEpkey.asc
Description: application/pgp-keys