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: domain of trustin@gmail.com designates
 64.233.184.195 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=Hvkd/Bp1Sj1/Z2jY21+i6zmpiVdJiRIbvsSH54IJsChS5oiemDFU6aLIcYsJrCpa9sx4isC2glcsZSDbfHH2eC7IsA0uwKi6w1aNGxYLbES1ErrdHo10yT8PSmb0OXHJlpczOIADOn0dbRcZ0H8EGZN+lOiFaoQ3PE6XkdQCkfU=
Message-ID: <768dcb2e0511170441g3173c724h@mail.gmail.com>
Date: Thu, 17 Nov 2005 21:41:56 +0900
From: Trustin Lee <trustin@gmail.com>
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [jira] Commented: (DIRMINA-121) Per-port filter chain
In-Reply-To: <437C7659.7000500@trillian.se>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_32661_28529048.1132231316726"
References: <75CFC296F70A08409390004F30EF9B8506968416@uk-ex001.groupinfra.com>
	 <437C7659.7000500@trillian.se>

------=_Part_32661_28529048.1132231316726
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

2005/11/17, Niklas Therning <niklas@trillian.se>:
>
> Another thing just struck me. The NextFilter given to the filter in
> IoFilter.init() is (as far as I can see) useless to the filter. There's
> no use for a NextFilter unless you have an IoSession. You can't fire an
> asynchronous event on the NextFilter instance specified in init() unless
> you have a session as well. And whenever an IoFilter is given to an
> IoSession (messageReceived, sessionOpened, etc) a NextFilter is also
> provided.
>
> IoFilter.init() should either be changed into
>
> void init( IoFilterChain parent, NextFilter nextFilter, IoSession
> session ) throws Exception;
>
> or
>
> void init( IoFilterChain parent ) throws Exception;


Actually, there is IoFilterChain.getParent() so you can get IoSession. :)

But I love the first option because it makes a user to implement his or her
init / destroy() method.

The first option would mean that you can't call init() on a filter until
> it is actually in use for a particular session which means that the
> chain can not be constructed until a session has been created. Second
> option means you can't get hold of a NextFilter for asynchronous events
> until another event has been generated on a particular session in the
> usual way.
>
> 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?


SSLFilter start SSL handshake as soon as it is added to the chain, so it
requires NextFilter.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/

------=_Part_32661_28529048.1132231316726
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div><span class=3D"gmail_quote">2005/11/17, Niklas Therning &lt;<a href=3D=
"mailto:niklas@trillian.se">niklas@trillian.se</a>&gt;:</span><blockquote c=
lass=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); ma=
rgin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Another thing just struck me. The NextFilter given to the filter in<br>IoFi=
lter.init() is (as far as I can see) useless to the filter. There's<br>no u=
se for a NextFilter unless you have an IoSession.&nbsp;&nbsp;You can't fire=
 an<br>
asynchronous event on the NextFilter instance specified in init() unless<br=
>you have a session as well. And whenever an IoFilter is given to an<br>IoS=
ession (messageReceived, sessionOpened, etc) a NextFilter is also<br>provid=
ed.
<br><br>IoFilter.init() should either be changed into<br><br>void init( IoF=
ilterChain parent, NextFilter nextFilter, IoSession<br>session ) throws Exc=
eption;<br><br>or<br><br>void init( IoFilterChain parent ) throws Exception=
;
</blockquote><div><br>Actually, there is IoFilterChain.getParent() so you c=
an get IoSession. :)<br><br>But I love the first option because it makes a =
user to implement his or her init / destroy() method.<br></div><br><blockqu=
ote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204=
); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The first option would mean that you can't call init() on a filter until<br=
>it is actually in use for a particular session which means that the<br>cha=
in can not be constructed until a session has been created. Second<br>optio=
n means you can't get hold of a NextFilter for asynchronous events
<br>until another event has been generated on a particular session in the<b=
r>usual way.<br><br>Does anyone else see this is or am I just being stupid?=
 :) Is anyone<br>using the NextFilter provided in init() and can prove me w=
rong?
</blockquote><div><br>SSLFilter start SSL handshake as soon as it is added =
to the chain, so it requires NextFilter.<br></div></div><br>Trustin<br>-- <=
br>what we call human nature is actually human habit<br>--<br><a href=3D"ht=
tp://gleamynode.net/">
http://gleamynode.net/</a>

------=_Part_32661_28529048.1132231316726--