directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Therning <nik...@trillian.se>
Subject Re: [jira] Commented: (DIRMINA-121) Per-port filter chain
Date Thu, 17 Nov 2005 13:06:35 GMT
Irving, Dave wrote:

>>Does anyone else see this is or am I just being stupid? :) 
>>Is anyone using the NextFilter provided in init() and can prove me
>>    
>>
>wrong?
>
>I agree - you cant do anything until you know a session, because all
>filter events are associated with a session.
>
>  
>
>>/Niklas
>>    
>>
>
>Dave
>  
>
So you agree that IoFilter.init( IoFilterChain parent, NextFilter 
nextFilter ) doesn't make any sense?

I think this is very important since if it should be

init( IoFilterChain parent, NextFilter nextFilter, IoSession session )

instead it means that you will *never* be able to add an IoFilter to an 
IoFilterChain unless there's a session. And that means that there *can't 
be* any sessionManagerChain or portChain. It would work like I outlined 
earlier today. The IoAcceptor/IoConnector simply has an ordered list of 
name to filter mappings and the same for each port. The chain isn't 
created until there is a session.

If it should be

init( IoFilterChain parent )

you could either use a "hack" to get hold of the session like in 
SSLFilter. The code looks like this:

init(parent, nextFilter)
{
    Object managerOrSession = parent.getParent();
    if( managerOrSession instanceof IoSession )
    {
        createSSLSessionHandler( nextFilter, ( IoSession ) 
managerOrSession );
    }
}

Or forget about asynchronous events (no matter how you get hold of the 
session for your asynch event I think it would be more or less a hack).

I would prefer the first solution.

/Niklas


Mime
View raw message