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] Refactoring MINA IoFilterChain (Was: IoFilters:
 DIRMINA-121 / 122)
Date: Tue, 15 Nov 2005 14:38:27 -0000
Message-ID: <EA9D95F907E2924A9A32F274114BCDEF8064F4@perth.Cellectivity.local>
Thread-Topic: [mina] Refactoring MINA IoFilterChain (Was: IoFilters:
 DIRMINA-121 / 122)
thread-index: AcXp7P4JrKJWupZCROWyPUCq7Q6c+wAAR02w
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 may be mistaken, but it seems to me the whole reason for this is to
be
> >able, eventually, to specify a chain in a spring based model and set
it
> >up during configuration. Am I off the mark here?
> >
> >Wouldn't it be simpler (or less disruptive) to simply configure some
> >other object (lets say a ChainBuilder) with all the filters one
> >requires, and during execution (the call to build) it will just add
all
> >the filters to the chain programmatically. No need to re-engineer
> >everything just one smart spring aware builder.
> >
> >Would this solve any of the user patterns we are trying to deal with
in
> >here?
> >
> >
> >
> I've actually thought of adding such a feature to the
> AbstractIoAcceptorFactoryBean. I think it would require a proxy for
the
> real IoHandler which intercepts sessionCreated() and simply adds the
> appropriate port-specific filters to the session's filter chain before
> forwarding to the real IoHandler. It's not a bad idea at all and I
might
> do it that way in the meantime. Thanks for pointing that out! :)
>=20

But remember the spirit of 121/122 is that you will have port level
filters.
The builder will configure the port level filters (which as I understand
today gets cloned when a session is created). So in this scenario you do
not need to play with sessionCreated or anything, the spring configured
builder will just apply the filters during binding and then the
IoHandler is free to do whatever it requires.=20

Now, in this model it is very simple to define composite builders since
they just need to call the build method on each one of its components
passing the chain. This will allow a very simple and straight forward
composition patters.

> But I also think that the refactoring Dave is working on will make the
> code simpler to understand/maintain and give more flexibilty. Let's
see
> what he comes up with and take it from there.

Simplification is good, and I am all for it. But the current solutions
seem to be requiring exposing more and more things tat users can break
instead of less. That looks like more complexity to me. May be I am
mistaken.

To be truthful, I have not even look at the 0.9 code. I work in 0.8 and
the implementation there seem to be quite simple and easy to understand.
Filters do not have init/destroy calls which from the conversation here
seem to be causing a lot of trouble. To me filters should be as
stateless as possible (they can keep any state they want in the
session).

And finally (this is getting way too long), I do not think one should be
able to cache the NextFilter object, just like that. It sounds wrong to
me.
Instead, I would suggest providing two methods:

 1) String NextFilter.getCurrentFilterName() : allows a filter to get
its name on the chain (I would enforce names to be unique).

 2) NextFilter IoFilterChain.getNextFilterFor(String name) : returns the
NextFilter instance that can be use to send something across. If the
named filter is no longer in the chain, you get null or some exception.

With something like this I think one really can simplify things.

Comments?

Jose Alberto