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

Attachment: pEpkey.asc
Description: application/pgp-keys

Reply via email to