Zitat von Ashish <[email protected]>:
On Tue, Oct 27, 2009 at 3:14 PM, <[email protected]> wrote:
Well, I use version 2.0M6 and I have trouble with the order of filters.
I created a protocol encoder/decoder and some filters. The filters
extend IoFilterAdapter and overwrite messageReceived/Sent.
This works well for for inbound messages, the protocol is used first
and than the filters are used on their order.
The trouble starts outbound. I would expect that the filter chain is
processed in the reverse order but id did not! The filters are called
in the same order as the for the inbound messages. Is this the designed
behaviour? Any ideas?
This is how it works today :-(
This is going to change in 3.0, where we plan to have different chains
for incoming and outgoing messages.
It shall be a while before you get to use 3.0
I do not understand why you need two chains? The filters are bidirectional,
messageReceived and messageSent. The only issue is the order, because
it does not work as described in the wiki. The session.write method
should only call the filters in the reverse order.
I want to use a protocol, filter 1-5 and a handler. The handler should
be able to send back a message. The message back should be processed by
filter 5,4,3,2,1 and the protocol. That's how I interpret the architecture
diagram on the wiki and how it makes sense for me. For me the current
behaviour is a bug, it simply doesn't make sense. I dare the claim that
nobody implemented sent and receive in one filter.
I created an issue (DIRMINA-744) just before I read your answer.
The only solution I see is that each filter has to find the next filter by
itself. It could use the session to get the filter chain, find myself and
call messageSent of the predecessor. No comment about quality of code.
Since I think the changes in MINA are minimal to reverse the order
for sending. How about an option/configuration that changes the order?
The filter chain already has a method getAllReversed(). This would allow
to match the architecture diagram on the wiki on one hand and allow
compatibility where it is needed.
