Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [jira] Commented: (DIRMINA-121) Per-port filter chain
Date: Thu, 17 Nov 2005 15:32:49 -0000
Message-ID: <75CFC296F70A08409390004F30EF9B8506968422@uk-ex001.groupinfra.com>
Thread-Topic: [jira] Commented: (DIRMINA-121) Per-port filter chain
Thread-Index: AcXrijlpwNWsOGN5RkKer8v1S4x6TgAAVApQ
From: "Irving, Dave" <dave.irving@logicacmg.com>
To: "Apache Directory Developers List" <dev@directory.apache.org>

Hi,

> I proposed a very simple solution earlier today which in short means
that the chain for a session isn't created=20
> until the session is actually created. It will be extremelly simple to
implement but there *might* be some overhead=20
> involved in creating the chain.

I think we'd all agree that if theres a simple solution then we should
go for that

> Dave, you seem to be confident that you can sort this out without
having to create a new chain when a new session is created.

The thing my solution would do is solve the NextFilter problem.
How does the simple solution solve the NextFilter problem? Is a whole
new chain constructed for each session with a new NextFilters? Sorry if
this was already discussed - there's been so much conversation today I
may have missed it :o)
And if the NextFilters per chain ** are ** different per session, can we
live with that? (I.e, it means that if a filter wants to fire an event,
it must map sessions to NextFilters - or must look it up).


Dave

-----Original Message-----
From: Niklas Therning [mailto:niklas@trillian.se]=20
Sent: 17 November 2005 15:18
To: Apache Directory Developers List
Subject: Re: [jira] Commented: (DIRMINA-121) Per-port filter chain

It's been a really interesting and fun discussion today! :)

To summarize:

sessionCreated() can not be relied upon to do filter initialization
since if the filter is added to a chain after the session was created
sessionCreated() won't be called. This means that IoFilter.init() is
needed and it has to be called when added or at least before the first
time any of the other IoFilter-methods is called. And in IoFilter.init()
we know there will be times when we need to get a hold of the session
(see SSLFilter) so IoFilter.init() has to be called every time it is
added to a session. My conclusion is that we should add the session in
the call to init():

void init(IoFilterChain parent, NextFilter nextFilter, IoSession
session)

Can we all agree on this now?

I proposed a very simple solution earlier today which in short means
that the chain for a session isn't created until the session is actually
created. It will be extremelly simple to implement but there *might* be
some overhead involved in creating the chain.

Dave, you seem to be confident that you can sort this out without having
to create a new chain when a new session is created. I do not doubt
that. If you still think it's worth it why don't you have a shot at it?=20
The question is how complex it will be and if it really will be that
much efficient.

/Niklas


This e-mail and any attachment is for authorised use by the intended recipi=
ent(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 recipien=
t then please promptly delete this e-mail and any attachment and all copies=
 and inform the sender. Thank you.