Hate replying to my own messages :-( See not at the end. > -----Original Message----- > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > Sent: 09 November 2005 11:25 > To: Apache Directory Developers List > Subject: RE: [mina] Filter management (was Spring Integration) > > > From: Niklas Therning [mailto:[EMAIL PROTECTED] > > > > 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 >
