On 6/21/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
Enrique Rodriguez a écrit :
...
> It would help MINA developers to know
> whether to use the IoHandlerChain or not.
If you are going to use a Chain patter, then I guess that the important
point is to think about the problem it solves. For instance, monitoring
by inserting loggers could be a good usage. But the main advantage of
chain parttern is its versatility : you can change the order of
handlers, or simply add or remove handlers on demand. If you never do
that, then using a chain pattern is questionable (IMHO).
You can also use it to share chain links. And links are shared
between Change Password and Kerberos, since they both work with
tickets and principals and they both have to perform some of the same
validation and security checks.
...
Method 2 is slightly better, because it keeps the decompaosition as it
was in the chain. The main problem is that you can easily factorize
their usage, and it's impossible to tests, as each method is private
Nothing says these couldn't be package or protected if you want to test.
So I would favor method 3, where we don't use instances of classes, but
static methods. So each IoHandlerCommand inherited class can be kept
with a very minor refactoring.
The problem with static access is we may wish to set instance state
since some of the commands are shared, today in Change Password and
Kerberos and I can see some need in DNS, when it is acting as both a
client and server.
But, this is barely different than #3, just an instantiation of a
class before calling the method to execute.
FWIW, this is how the protocols were originally written, before
IoHandlerChain support was added to MINA. The problem here isn't the
pattern, but rather the implementation. Much of the problem you are
reporting is due to the bi-directional nature of the MINA chains,
which is a feature we never use anywhere and which leads to the
maintenance of the position in the chain and the big stack traces.
Enrique
