directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niklas Therning" <nik...@trillian.se>
Subject RE: [mina] Filter management (was Spring Integration)
Date Thu, 10 Nov 2005 12:32:40 GMT
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/comm
on/IoHandler.html

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.

If you don't believe me please have a look at the code yourself:

http://directory.apache.org/subprojects/network/xref/org/apache/mina/transpo
rt/socket/nio/support/SocketSessionImpl.html

http://directory.apache.org/subprojects/network/xref/org/apache/mina/common/
support/IoSessionFilterChain.html

SocketSessionImpl clearly wraps the filter chain instance given to it (this
is the SocketAcceptor's chain) and it isn't copied.

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.

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).

/Niklas


-----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)

> 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.)
> 

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

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

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

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


Mime
View raw message