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: [mina] Filter management (was Spring Integration)
Date: Wed, 9 Nov 2005 11:42:57 -0000
Message-ID: <EA9D95F907E2924A9A32F274114BCDEF805EBD@perth.Cellectivity.local>
Thread-Topic: [mina] Filter management (was Spring Integration)
Thread-Index: AcXj1JCIBXDoiid7TumNjkLmAAywyQBR6fEQAAGACoA=
From: "Jose Alberto Fernandez" <jalberto@cellectivity.com>
To: "Apache Directory Developers List" <dev@directory.apache.org>

Hate replying to my own messages :-( See not at the end.

> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:jalberto@cellectivity.com]
> Sent: 09 November 2005 11:25
> To: Apache Directory Developers List
> Subject: RE: [mina] Filter management (was Spring Integration)
>=20
> > From: Niklas Therning [mailto:niklas@trillian.se]
> >
> > BTW, I have some refactoring suggestions regarding binding. Let's
say
> I
> > have an HTTP IoHandler implementation and I want to support both SSL
> and
> > non SSL traffic. Right now there's no way for me to use a single
> > SocketAcceptor and say that traffic coming in on port 80 should not
go
> > through an SSLFilter while traffic coming on port 443 should. It
would
> > be cool if this would be possible. To be able to do this right now I
> > would either have to use two SocketAcceptors, one for 80 and one for
> > 443, which have different filter chains or add logic in my IoHandler
> to
> > add the SSLFilter to its filter chain if the client came in on port
> 443
> > (I guess a custom filter could also do this).
> >
> > So, I would like to have a bind method which takes a triplet:
> >
> > bind(SocketAddress address, IoFilterChain filterChain, IoHandler
> handler)
> >
> > There would still be a root filter chain on the IoAcceptor which
would
> > be called before the extra chain associated with the port.
> >
> > WDYT?
> >
>=20
> I have some problems with this approach because it disassociates
> filtering from the service, in particular when you think of Protocol
> level implementations, where you may want to apply filters at the IO
> level (like SSL) and at the Protocol Level.
>=20
> My suggestion would be to provide two additional interfaces:
>=20
> Public interface IoFilterManager {
>=20
>    Public void configureFilters(IoFilterChain chain);
>=20
> }
>=20
> Public interface ProtocolFilterManager {
>=20
>    Public void configureFilters(ProtocolFilterChain chain);
>=20
> }
>=20
> An IoHandler or ProtocolProvider that implements the IoFilterManager
> interface will be called during the binding/connecting process to give
> it a chance to make changes to the IoFilterChain to be used when
> processing IO by the IoAcceptor/IoConnector.
>=20
> By the same token, a ProtocolProvider that implements the
> ProtocolFilterManager interface will be called during
binding/connecting
> process to make changes to the ProtocolFilterChain to be used at the
> ProtocolLevel.
>=20
> The advantages of this approach are:
>=20
> 1) You modify the filter chain only once, and not each time a
connection
> is created.
>=20
> 2) You have full control over the chain and can do any modifications
one
> may need.
>=20
> 3) It is backward compatible, as it is completely optional.
>=20
> What do you think? Would this fit in the spirit of MINA?
>=20

Alternatively, an additional argument could be passed to bind/connect
(in the spirit of Niklas suggestion) that implement one or both
interfaces.
This may be more suitable pattern for the case of HTTP/HTTPS.

> Jose Alberto
>=20