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:25:16 GMT
> 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?

Jose Alberto



Mime
View raw message