Hi, Trustin:
Yep - I just installed mina 1.1.2, and ByteBuffer now passes the test.
Thanks again for the swift help.
Yigal
Yigal Rachman wrote:
Hi, Trustin:
I ran your test case on my system and had the following error (which is
actually different from what I am seeing!)
Exception in thread "main" java.lang.AssertionError:
expected:<12> but was:<3>
at org.junit.Assert.fail(Assert.java:71)
at org.junit.Assert.failNotEquals(Assert.java:451)
at org.junit.Assert.assertEquals(Assert.java:99)
at org.junit.Assert.assertEquals(Assert.java:116)
at
ca.uvic.dmas.domain.daf.driver.codec.textline.TextLineCodecHarness.main(TextLineCodecHarness.java:26)
The assertion on buffer.limit() failed.
I am running mina 1.0.1 - maybe it is time to upgrade, eh?
Thank you for your help,
Yigal
Trustin Lee wrote:
On 10/16/07, Yigal Rachman <[EMAIL PROTECTED]> wrote:
Hi, Folks:
When ByteBuffer.getString() breaks midway because of a
CharacterCodingException, it fails to restore the position and limit;
thus getString() is destructive when this happens. One can, of course,
work around this, but it should not be necessary.
Could you please specify some example code that reproduces the
problem? We already have a test case for the same case, and it seems
to work fine:
public void testGetStringWithFailure() throws Exception {
String test = "\u30b3\u30e1\u30f3\u30c8\u7de8\u96c6";
ByteBuffer buffer = ByteBuffer.wrap(test.getBytes("Shift_JIS"));
// Make sure the limit doesn't change when an exception arose.
int oldLimit = buffer.limit();
int oldPos = buffer.position();
try {
buffer.getString(3, Charset.forName("ASCII").newDecoder());
Assert.fail();
} catch (Exception e) {
Assert.assertEquals(oldLimit, buffer.limit());
Assert.assertEquals(oldPos, buffer.position());
}
try {
buffer.getString(Charset.forName("ASCII").newDecoder());
Assert.fail();
} catch (Exception e) {
Assert.assertEquals(oldLimit, buffer.limit());
Assert.assertEquals(oldPos, buffer.position());
}
}
HTH,
Trustin
|
