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)
Message-ID: <43725E44.4080700@trillian.se>
Date: Wed, 09 Nov 2005 21:38:28 +0100
From: Niklas Therning <niklas@trillian.se>
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [mina] Filter management (was Spring Integration)
References: <EA9D95F907E2924A9A32F274114BCDEF805EB9@perth.Cellectivity.local>
In-Reply-To: <EA9D95F907E2924A9A32F274114BCDEF805EB9@perth.Cellectivity.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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, please
correct me if I'm wrong.)

>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.
>  
>
Providing an IoFilterChain at bind time is a one time operation as well.
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 have
their private chain.

>2) You have full control over the chain and can do any modifications one
>may need.
>  
>
You still have the same problem: there is a 1:1 relationship between an
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 ServiceRegistry
all other Services sharing that TransportType will have their chains
modified since they are in fact using the same chain.

>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 IoFilterChain.
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 to
configure it.

/Niklas