On Thu, Feb 26, 2009 at 12:45 PM, Emmanuel Lecharny
<[email protected]> wrote:
> David Rosenstrauch wrote:
>>
>> So I'm wondering a few things:
>>
>> * Should this implementation of CumulativeProtocolDecoder be considered
>> buggy (in that it causes different behavior when using DummySessions)?
>
> No. Use your own drafted Session class to make the decoder happy. Using a
> DummySession expecting it has the same features than the normal Session
> implementation is not a good idea. The DummySession was just created to
> handle some tests whre we don't care handling corner cases.
>>
>> * Is there any reason why the CumulativeProtocolDecoder needs to handle
>> the dummy (non-fragmentable) session differently? Would it not be possible
>> to have a single set of code that works identically for both?
>
> Again, the dummySession has not been written as a general representation of
> a session. It's 'dummy'...
AFAIK, its more for Unit Testing with a default (dummy) session
implementation. The scope of Unit testing is just the Unit in
isolation.
>>
>> * If this isn't considered a bug, then is there any cleaner way for me to
>> work around this situation?
>
> Writing your own session class is one way to get rid of your problem, or
> just use a real session, and launch a real server (a bit more complex, as
> you have to pick an available port).
>
> Maybe having a richer Session implementation for testing purpose would be a
> good idea. You can fill a JIRA proposing such an evolution.
On a similar note, on your code snippet
while (in.hasRemaining()) {
...
decoder.decode(session, in, decoderOut);
}
call decode only when the message is complete. For each iteration
calling this can be expensive. Something like isMessageComplete()
implementation, which tells you when the message can be decoded and
then call decode.
thanks
