Zitat von Emmanuel Lecharny <[email protected]>:
I write a middle-ware application that communicates with different
partners and has to adapt the different protocols. The protocols are
usually binary protocols. The communication uses client only, server
only or server and client sockets for communication. The communication
direction is bidirectional, both sides can cause messages. One protocol
uses a client and a server socket, one direction of the socket is the
main direction the other is used for acknowledgements only. We currently
have a back-end that is able to parse the message and normalise it for
further processing. The back-end requires a unique message identifier
for each message. I thought that I can use a filter that adds an
identifier to the message inbound and strips the identifier outbound.
The same is true for other information, checksums, message type, sender
and receiver information and so on. That's the place where I thought the
filters are useful, having piped Unix commands in mind. The idea is to
adapt to new protocols simply by configuring new filters, e.g. adding a
filter that converts a XML message into the normalised message format
and vice versa. We could change the normalised format to e.g. XML simply
by adding a filter. I think I have to create a handler that implements
my own filter chain.
Sadly, yes. The main issue we have (and you can read about it in the
page I mentioned above) is that we are transfering IoBuffer from filter
to filter. This is a major design flaw we want to fix in 3.0, as it
forbids you to chain codecs. This makes it a bit difficult to use
filters, and most certainly you hit this wall here.
We have had the same issue in Apache Directory project, and we have had
to implement the codec in a certain way in order to make it work, as it
was a two stage decoder. Not really easy...
Could you please explain?
I must admit that the current impl is also a perfect maze... Debugging
MINA is just requiring a very high IQ :/
Doesn't that make you think?
Another thing I tried is the implementation of
filterChain.getAllReverse() gives you the reverse ordered filters. But
if you ask the retrieved list with getNextFilter() on you get the old
order. I would assume that you get the reverse order too, but you will
probably answer that it works as designed. I can't argue about this.
All of this is quite frustrating, I think I have to create my own filter
chain as handler. That's the only solution I see that matches my time frame.
Probably... Sorry for that, the current code is not perfect, and this
is the reason we are really impatient to start the 3.0 version.
And again. I can not use a handler to implement my own filter chain.
The handler (messageSent) is to late on the outbound side. What to filter
if it's already sent?
If I want to create my own filter chain I need to implement it as a filter,
not a handler. I already implemented a ProtocolEncoder, ProtocolDecoder using
a ProtocolCodecFilter. How can I reuse this component?
