Continuing from my previous numbering...
4)
websocketmessage.WSClient.java#byteBufferToBinaryTest_from_standalone
This test sends four messages with the same ByteBuffer as the payload.
For the first message the ByteBuffer is:
java.nio.HeapByteBuffer[pos=0 lim=42 cap=42]
For the second it is:
java.nio.HeapByteBuffer[pos=42 lim=42 cap=42]
at which point the test fails.
Clearly the ByteBuffer is read when the first message is sent so there
is no content left when the second message is sent. Is this a bug in the
TCK or should WebSocket client implementations be taking steps to ensure
ByteBuffers (and particularly pos and lim) are unchanged? Personally, I
am leaning towards a TCK bug.
5)
WSClient.java#pongToPongTest_from_standalone appears to have the same
problem as 4)
6)
What are the allowed values of T for implementations of
MessageHandler.Whole<T> and MessageHandler.Partial<T>. My assumption
(based on OnMessage) is:
Whole:
String, Java primitive or class equivalent, Reader, any class with a
decoder, byte[], ByteBuffer, InputStream
Partial:
String, byte[], ByteBuffer
7) WSClient.java#addMessageHandlersTest_from_standalone
addMessageHandlersTest() contains the following lines (182-183)
data.put(("BasicByteBufferMessageHandler added").getBytes());
session.getBasicRemote().sendBinary(data);
There is a data.flip() missing between those.
8)
WSClient.java#addMessageHandlerBasicByteBufferTest_from_standalone
Same issue as 7. There is a missing SENT_BYTE_MESSAGE.flip() in the
client for this test.
Thanks again for early access to the TCK. It has been very useful as it
has highlighted a handful of small bugs and a couple areas where I still
have some work to do. I hope my feedback is equally useful and I look
forward to the next draft of the TCK.
Cheers,
Mark