...
Introduction
This filter is one of the most important one. In many case, writing a MINA based application without having such a filter added is not really meaningful.
...
The factory is pretty simple. It offers two methods :
...
...
...
We can see that those two methods have a single parameter, an IoSession, which is a bad idea. A codec should not depend on a session. In fact, not a single codec uses this session, and I think that it should be removed.
Moreover, it forces the encoded and decoder instances to be created only when the first message is received, which can be a hassle, as ithe encoder/decoder creation has to be synchronized. It would be way better to create those instances when the filter is created.
It's also possible to pass the encoder and decoder directly, as a factory will be created internally to encapsulate those two methods.
...
The encoder and decoder are stateless, we don't need to pass a session object to the getEncoder/Decoder() methods.
...
Thre is another problem : if we add this codec in the chain after the session has been created, then the encoder and decoder are never added into the session attributes, which is bad. This is addressed in
https://issues.apache.org/jira/browse/DIRMINA-635
...
- We don't have anymore bytes in the incoming request : just close everything
- We have some more bytes, and we can decode a full message out of them : decode the message, and go back to step (1)
- We have some more bytes, but we can't decode a full message out of them :throw an exception
Note I'm not sure that we should decode anything when we receive a sessionClosed message : The session is already closed, and any other treatment may violate the client's will.
OnPreAdd
This event is received when we try to insert this filter during a session. What it does is very simple :
...
We also have a special case : we received an object which is not a byte buffer.
...
...
Seems like a nonsense to me. How possibly can we go through the decoder with something we don't want to decode ?
...
Generally speaking, the way the decoder works is exposed in the following pseudo-code :
...
...
The callback system is a bit annoying. The idea is that once the decoder has found a message, it pushes it into a queue, and at the end, we have to do a flush() on the resulting queue : the callback holds the decoded message and the mechanism to process them (here, to call the next filter).
I think it would be way easier to get a list of decoded messages as a return from the decoder, and then loop on this list in order to keep the logic into the Codec filter, instead of delegating this logic to an external class.
A better solution, IMHO, would be to call the decoder, which will return a message or nothing (if we don't have enough bytes), and push this message to the next filter, until we can't decode anything else :
while ( ( message = decode( bytes ) ) != null ) {
nextFilter.messageReceive( message )
}
...
...
Another aspect would be to make the decoder to push the result as a stream, which will be handled by the next filter : this will allow a multi-layered decoder to be written. Decoding ASN.1 encoded PDU will typically benefit from such an approach.
...
We just do nothing in this case. We don't even have to call the next filter.
...
...
I don't think this is a possible case, as this filter will be invoked after some bytes has been read from the socket. Anyway ...
...
2) We received a byte buffer which is not enough to generate a message
...