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)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [mina] Filter management (was Spring Integration)
Date: Thu, 10 Nov 2005 11:05:31 -0000
Message-ID: <EA9D95F907E2924A9A32F274114BCDEF805FFD@perth.Cellectivity.local>
Thread-Topic: [mina] Filter management (was Spring Integration)
Thread-Index: AcXlbhoCq/TXwKJMRQCLTfeU4Zp+XQAd3znA
From: "Jose Alberto Fernandez" <jalberto@cellectivity.com>
To: "Apache Directory Developers List" <dev@directory.apache.org>

> From: Niklas Therning [mailto:niklas@trillian.se]
>=20
> Jose Alberto Fernandez wrote:
>=20
> >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
>=20
> bind(Service s, IoFilterChain chain, Iohandler handler)
>=20
> method in addition to the current bind() method.
>=20
> 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.)
>=20

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
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.
>=20

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
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.
>=20

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.
>=20
> >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.
>=20

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