Haug Bürger wrote:
I wonder what happens if you chain the SSL and the logging filter.
Surprisingly, it works ! At least, if the SSL filter is the first in the
chain :)
Ok, here, we have a potential situation here : this SSL filter *must* be
the first in the chain.
As this is nothing but logical, we think that the SSL filter must be
removed from the chain and be put before the chain is called (this is
discussed here : http://mina.apache.org/mina-30-design.html)
How
do you configure your system to log the data not crypted. Both
directions, inbound and outbound? If SSL is the first filter and logging
is the second, inbound you log the data not crypted. Outbound you log
crypted data. Is that right?
Well, the SSL filter is not responsible for encryption or description.
It's just used to handle the handshake between the client and the
server, as the SSL layer is handled by the socket itself.
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.
But the diagram is just to express that messages are going through the
filters and back to the client. Probably need an extra explaination to
eliminate possible confusion about the order.
Yes this very confusing and misleading. And what makes it most confusing
is that you have a messageSent and messageReceived method. From what I
understand the direction is not important.
true.
If the IoService wants to
push a message to the handler it uses the IoFilterChain filter 1,2,3 and
the output is passed to the handler. In the other direction the
IoHandler also uses the IoFilterChain filter 1,2,3 and the output is
passed to the IoService.
right.
And that you mention the servlet filter is even more confusing because
it works different.
right.
It also doesn't match the filter definition of Unix
or DOS command line filters. In these cases filters are something different.
Most certainly. However, 'Filter' can have more than one semantic, and
it's really difficult to define it by comparing the other semantics in
use. How does it compare to a filter used in a car for instance?
So we stick to the basic definition for filter : it takes some input, do
some transformation, and produce an output. Whatever it is inbound or
outbound.
What you do is executing a list of functions on the data. You can argue
that this is filtering and that splitting it to send and receive avoids
a if inbound then else. For me your filtering is using a function on the
data in different contexts, inbound and outbound.
I don't think it does matter a lot what you or me are thinking about
what a filter is doing :) What is important is that the doco does not
spread confusion ...
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.
Wed'd rather think about defining the two chains and let the user
configure it. In any case, that will end with the same result.
What's is puzzling is that the current implementation, no matter how
weird it sounds to you, and no matter how irrelevant is the doco (!)
is doing its job fine :)
In any case, can you just tell us about your implementation problem,
so that we can give you a hand ?
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...
I messed around with the filter chain to fool MINA by adding the "right"
next filter at the end of each messageSent method. But that doesn't seem
to work easily because yo can not access the previous filter because it
is not part of the interface. What really bugs me is that it is part of
the implementation (EntryImpl).
You can still add a filter somewhere in the chain dynamically as soon as
you know the name of each filter.
I must admit that the current impl is also a perfect maze... Debugging
MINA is just requiring a very high IQ :/
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.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
