Not necessarily, for three reasons :
1) if the chain is fixed at startup, you can't anymore inject a
LoggingFilter when the server is running. You can only activate or
desactivate it. Not that it's realy a big issue, but it may help in
some case (that also mean we have a way to control the execution. JMX ?)
One normally doesn't turn on and off things like that on a per message
basis. What I mean by that is that each filter decides to do what it
needs to do. That includes logging. Constantly injecting logging
filters on an ad hoc basis is a very, very, poor practice.
A very, very rare practice, hopefully :) Here, i'm not sure it worth it
anyway. I really think it's better to enable the filter instead of
injecting it dynamically. In any case, I'm ready to lose this "feature"...
2) Most important, if we don't have a clue about which is the next
filter in the chain, that leads to problem when debugging, as you
can't know which filter will be called. Ennoying
Sure you do. The chains are fixed. If you know what filter you are
and what state you're in you know what filter gets called next from
the perspective of the framework. From the perspective of the filter
you shouldn't care what's next, if you do then you've introduce a
brittle dependency. For me that;s usually a red flag that I haven't
thought through a design and it needs to be revisited.
Let me clarify my mind : when stepping through filters while debugging,
I want to be able to jump directly to the next filter. In order to do
that, code like :
Filter nextFilter = computeNext( session );
nextFilter.call( session );
is mandatory. I don't want to experiment the same pain as with Spring,
when I have to open two editors, one for my java code, and another one
to see what is supposed to be my SM. I went through this pain so many
times in the past with MINA that I don't want to suffer such a pain again...
3) Last, not least, we want to be able to call the next filter in the
middle of a processing :
messageReceived() {
do blah();
if ( condition ) {
do anotherBlah();
call Next filter();
} else {
do yetAnotherBlah();
call nextFilter();
}
do endingBlah();
}
That just tells me that you have mixed up two states into one and that
you need to expend a little more effort into your state machine design.
From the user POV, it's way more easy to write code this way than to
create two (or more) states. The idea is to combine the state machine
vision with the chain vision. You can express everything with a SM, and
implement it in a simpler way...
Not sure this is possible in another way than with those computed
nextFilter() inside the filters.
I agree but it's my contention that it's a bad practice that supports
an ill thought out protocol.
The biggest advantage is that it eases the implementor work most of the
cases. Now, it does not preclude that we should not allow someone to
implement his protocol using a complete state machine. May be we should
provide both mechanisms :
- one which is driven by the code (ie, the code 'pull' the next step),
- one which is driven by the state machine (your way).
(well, t's always possible to express this with more transitions and
states, but t would be more complicated to write filters then...)
I'm looking at your messageReceived() method and am thinking that you
have provided me with a perfect example for state programming. Only
the original author of that method would know what's going on.
Most certainly :) However, this was a complex example, usually, it's way
more simple.
I don't say that you are plain wrong, in fact, I share most of your
vision, but I'm just wondering if this would not render the protocol
implementors way more complex.
I may try to see what would be the impact of the plain SM approach when
applied on the current implemented protocols.
Thanks !
