directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: [mina] Filter management (was Spring Integration)
Date Thu, 10 Nov 2005 11:05:31 GMT
> From: Niklas Therning []
> Jose Alberto Fernandez wrote:
> >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.
> >
> >
> I might be mistaken but are you talking about Services and
> ServiceRegistry? ServiceRegistry would of course have a
> bind(Service s, IoFilterChain chain, Iohandler handler)
> method in addition to the current bind() method.
> BTW, In MINA 0.9.x there is no ProtocolProvider anymore. IoHandler
> serves the same purpose as ProtocolProvider used to do. (Someone,
> correct me if I'm wrong.)

I doubt this is the case as all the methods in ProtocolHandlers have
completely different signatures.

> >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
> >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
> >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
> >is created.
> >
> >
> Providing an IoFilterChain at bind time is a one time operation as
> Probably done at configuration time. It would be very unwise to modify
> this filter chain at runtime since all sessions which connected on the
> bound port use the same filter chain. Each session still of course
> their private chain.

Well, this cannot be the case as you can modify the chain for a
particular session anyway you want on your Handler. Than means that
every session's FilterChain is actually copied.

The point of my approach is that it does not limit the handler to just
append filters but provides all the power available to the Session.

> >2) You have full control over the chain and can do any modifications
> >may need.
> >
> >
> You still have the same problem: there is a 1:1 relationship between
> IoAcceptor and the IoFilterChain. All sessions created from the same
> IoAcceptor will share this chain. If you modify it (in an
> IoFilterManager as you suggest) when you call bind() on
> all other Services sharing that TransportType will have their chains
> modified since they are in fact using the same chain.

Not true, see above.

> >3) It is backward compatible, as it is completely optional.
> >
> >
> We would still provide the old bind() methods both in IoAcceptor and
> ServiceRegistry so backwards compatibility would not be an issue.
> >What do you think? Would this fit in the spirit of MINA?
> >
> >
> >
> I think I wasn't clear enough on what the problem is. I would like to
> get rid of the 1:1 mapping between an IoAcceptor and its
> What I was proposing was to have an additional filter chain associated
> with the SocketAddress the Acceptor is listening on. How we configure
> that (my approach using new bind()-method or yours using the
> IoFilterManager interface) is secondary at the moment. The first
> priority is to change the IoAcceptor implementations and the way they
> handle IoFilterChains so that they can support this, then decide how
> configure it.

My problem with your solution is that you do not get full control of the
filter chain, you can only append to it. Why should be sell it short.

Jose Alberto

View raw message