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 13:06:22 -0000
Message-ID: <EA9D95F907E2924A9A32F274114BCDEF80606B@perth.Cellectivity.local>
Thread-Topic: [mina] Filter management (was Spring Integration)
Thread-Index: AcXlbhoCq/TXwKJMRQCLTfeU4Zp+XQAd3znAAAI5szAAAe84AA==
From: "Jose Alberto Fernandez" <jalberto@cellectivity.com>
To: "Apache Directory Developers List" <dev@directory.apache.org>

This sound quite distressing, are you saying that almost every piece of
MINA code on has needs to be rewritten if/when one wants to move to 0.9?

What do we gain with this? Less enforcing of typing? Or are you saying
that a IoHandlers may not be processing buffers?

Well I hope we still have ProtocolProviders as we need to specify codecs
somewhere? Or have they got rid of that too? How about separate filter
chains at the IO and Protocol levels they are needed for very different
purposes.

Hope someone is writing a guide on how to move from 0.8 to 0.9 if the
changes are this dramatic.

Finally, what will happen if I call addBefore("thisFilter", myFilter).
How can I be able to do that if no copy is made? Or have they got rid of
all those methods also?

Jose Alberto

> -----Original Message-----
> From: Niklas Therning [mailto:niklas@trillian.se]
> Sent: 10 November 2005 12:33
> To: 'Apache Directory Developers List'
> Subject: RE: [mina] Filter management (was Spring Integration)
>=20
> There IS no ProtocolProvider in Mina 0.9.x anymore. The old
> ProtocolHandler
> and IoHandler have been merged. In Mina 0.9.x IoHandler doesn't deal
with
> ByteBuffers directly as the old IoHandler used to do but take Objects
> instead. Please take a look at
>
http://directory.apache.org/subprojects/network/apidocs/org/apache/mina/
co
> mm
> on/IoHandler.html
>=20
> The IoFilterChain of a session wraps the IoFilterChain set on the
> IoAcceptor. This instance isn't copied and if you call addFirst() on
the
> filter chain of a session the filter you add will actually be added
AFTER
> the last filter of the IoAcceptor's filter chain. I agree that it
would be
> better if the chain would be copied and the complete chain would be
> modifiable but it just isn't at the moment.
>=20
> If you don't believe me please have a look at the code yourself:
>=20
>
http://directory.apache.org/subprojects/network/xref/org/apache/mina/tra
ns
> po
> rt/socket/nio/support/SocketSessionImpl.html
>=20
>
http://directory.apache.org/subprojects/network/xref/org/apache/mina/com
mo
> n/
> support/IoSessionFilterChain.html
>=20
> SocketSessionImpl clearly wraps the filter chain instance given to it
> (this
> is the SocketAcceptor's chain) and it isn't copied.
>=20
> BTW, if you want to modify the session's filter chain in your
IoHandler
> (which is what you propose since you want your IoHandler to implement
> IoFilterManager) you could do that in sessionCreated() today. If we
change
> the chain handling so that the IoAcceptor's chain isn't wrapped by
rather
> copied you could achieve full control at runtime as you wanted. But
you
> would then have logic in your IoHandler which determines whether e.g.
SSL
> should be enabled or not which is exactly what I don't want.
>=20
> And you STILL have the problem that there is a 1:1 relationship
between
> the
> IoAcceptor and an IoFilterChain. I want to have different filter
chains
> for
> different ports but still use the same IoHandler (e.g. for handling
HTTP
> and
> HTTPS without the IoHandler having to know about it). This is done
once at
> configuration time (in my case using Spring).
>=20
> /Niklas
>=20
>=20
> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:jalberto@cellectivity.com]
> Sent: den 10 november 2005 12:06
> To: Apache Directory Developers List
> Subject: RE: [mina] Filter management (was Spring Integration)
>=20
> > From: Niklas Therning [mailto:niklas@trillian.se]
> >
> > 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.)
> >
>=20
> I doubt this is the case as all the methods in ProtocolHandlers have
> completely different signatures.
>=20
> > >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.
>=20
> 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.
>=20
> > >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.
>=20
> > >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.
> >
>=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.
>=20
> Jose Alberto