directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Irving, Dave" <>
Subject RE: [jira] Commented: (DIRMINA-121) Per-port filter chain
Date Thu, 17 Nov 2005 13:19:37 GMT
> So you agree that IoFilter.init( IoFilterChain parent, NextFilter
nextFilter ) doesn't make any sense?

I agree that you cant fire events until there's a session to fire them
to :o)

IoFilter.init(IoFilterChain parent, NextFilter nextFilter) does make
sense if you want your init to fire an event.
Filters would never be inited until a session comes along.
My proposal does have a problem though: A shared (acceptor / port)
filter would only be inited / destroyed once (not per session) because
it's the NextFilter that contains the smarts (not the filter).
It means that per session init / destroy logic should come in
"sessionCreated" / "sessionDestroyed" and not "init".
"init" / "destroy" would be used for initialisation / tear-down of the
filter itself (e.g. acquiring / releasing resources).

This doesn't seem too bad to me given that any filter kicking out async
events is always doing so w.r.t an existing session.

Does that seem ok ish?

-----Original Message-----
From: Niklas Therning [] 
Sent: 17 November 2005 13:07
To: Apache Directory Developers List
Subject: Re: [jira] Commented: (DIRMINA-121) Per-port filter chain

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
>I agree - you cant do anything until you know a session, because all 
>filter events are associated with a session.
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.


This e-mail and any attachment is for authorised use by the intended recipient(s) only. It
may contain proprietary material, confidential information and/or be subject to legal privilege.
It should not be copied, disclosed to, retained or used by, any other party. If you are not
an intended recipient then please promptly delete this e-mail and any attachment and all copies
and inform the sender. Thank you.

View raw message