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
