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] IoFilters: DIRMINA-121 / 122
Date Tue, 15 Nov 2005 01:38:29 GMT
2005/11/15, Niklas Therning <niklas@trillian.se>:
>
> And that's where things get really tricky! ;-) Actually when I have a
> look at the code now I see that the concrete NextFilter instances are
> created only once and then used all the time. If my idea is going to
> work the NextFilter objects created by AbstractIoFilterChain will have
> to be created on each filter invocation. We need a new NextFilter
> implementation. Here's an example:
>
> public static class UpstreamNextFilter implements NextFilter {
> Entry head;
> IoHandler handler;
> public UpstreamNextFilter(Entry head, IoHandler handler) {
> this.head = head;
> this.handler = handler;
> }
> public void sessionCreated( IoSession session )
> {
> if (head != null) {
> head.filter.sessionCreated(new
> UpstreamNextFilter(head.nextEntry, handler), session);
> } else {
> handler.sessionCreated(session);
> }
> }
> public void sessionOpened( IoSession session )
> {
> if (head != null) {
> head.filter.sessionOpened(new
> UpstreamNextFilter(head.nextEntry, handler), session);
> } else {
> handler.sessionOpened(session);
> }
> }
> public void sessionClosed( IoSession session )
> {
> if (head != null) {
> head.filter.sessionClosed(new
> UpstreamNextFilter(head.nextEntry, handler), session);
> } else {
> handler.sessionClosed(session);
> }
> }
> ... (I think you get the point)
>
> In AbstractIoFilterChain sessionCreated() would look something like:
>
> public void sessionCreated( IoSession session, IoHandler handler )
> {
> Entry head = this.head;
> new UpstreamNextFilter(head, handler).sessionCreated(session);
> }
>
> There would also be a corresponding DownstreamNextFilter implementation
> (perhaps Upstream and Downstream can be combined into one) which takes
> an IoProcessor in its constructor instead of an IoHandler.
>
> One thing that strikes me now is that the NextFilter interface is almost
> the union of IoHandler and IoProcessor. Except that the methods of
> NextFilter aren't allowed to throw Exception. Maybe that fact could be
> used to simplify the API?


Hmm.. you're right. But I think it is essentially same with what we're doing
in AbstractIoFilterChain. It provides a default implementation of head/tail
filter and you can override it by overriding createHeadFilter and
createTailFilter.

Providing various nextfilter implementation will drive you into some trouble
because the order of the filters can change at any time. So you'll have to
switch the nextFilter property of Entry and it might not be thread-safe.
That's why I used head/tail filter instead, and you can still override the
implementation. :)

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

Mime
View raw message