directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <trus...@gmail.com>
Subject Re: [mina] Filter management (was Spring Integration)
Date Thu, 10 Nov 2005 16:33:46 GMT
2005/11/11, Jose Alberto Fernandez <jalberto@cellectivity.com>:
>
> public void sessionCreated( IoSession session ) throws Exception {
> session.getFilterChain().addFirst( "codec", new ProtocolCodecFilter(
> YOUR_CODEC_FACTORY ) );
> }
>
>  This is one place, where the approach I mentioned would make a lot of
> sense. You are running several protocols using several different handlers.
> You really do not want to specify on every session the adding of new
> CodecFilters, for example. You know all sessions will use the same filters
> and if your filters are stateless, they should be using the same one. It
> would make a lot of sense to be able to set this things once during bind()
> and not need to do it on every session creation.
>
For now, you can add ProtocolCodecFilter to IoFilterChain of
IoSessionManager to apply it to all connections managed by an acceptor or a
connector. This is not per-port way, but I suggested an API change in this
thread.

> I think you guys need to provide a migration guide as part of the 0.9stable delivery.
I just went to the MINA site and there is no info about all
> this changes (unless you go and look at the source code) if I where a user
> of MINA and I see the announcement of 0.9 and go and download it and then
> I learn I need to port all my code. I sure will be quite disappointed that
> no one mentioned this in very large letters. It would also be nice if there
> were some sort of utility classes that would allow one to bridge between the
> old interfaces and the new ones. My be some proxy classes classes and
> interfaces can be provided to simplify this.
>
Please note that our versioning strategy is that of Linux. 0.9 (odd) is
unstable release. 0.8 (even) is stable. The API and feature set of 0.9 and
0.9.1 can be different dramatically.

> Good, that was my understanding too. I guess my suggestion was to make a
> copy on the bind/connect which are fewer that the number of sessions that
> will be opened. Clever programming here may allow for the copy only to occur
> once a chain is modified which will make things much cheaper.
>
The chain can be modified in runtime, but it is not thread safe strictly
speaking. But it should work fine in most cases.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/

Mime
View raw message