directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: [mina] Filter management (was Spring Integration)
Date Wed, 09 Nov 2005 11:42:57 GMT
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)
> 
> > 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?
> >
> 
> 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.
> 
> My suggestion would be to provide two additional interfaces:
> 
> Public interface IoFilterManager {
> 
>    Public void configureFilters(IoFilterChain chain);
> 
> }
> 
> Public interface ProtocolFilterManager {
> 
>    Public void configureFilters(ProtocolFilterChain chain);
> 
> }
> 
> 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.
> 
> 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.
> 
> The advantages of this approach are:
> 
> 1) You modify the filter chain only once, and not each time a
connection
> is created.
> 
> 2) You have full control over the chain and can do any modifications
one
> may need.
> 
> 3) It is backward compatible, as it is completely optional.
> 
> What do you think? Would this fit in the spirit of MINA?
> 

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
> 


Mime
View raw message