I am looking at Derby-285
Network Client should not print non-ascii token separators in message
when it cannot connect to the server to retrieve the error message
These characters break Jira Export if a Network Client trace is put into
Jira.
Currently the message tokens get sent by the server to the client in the
SQLERRMSG_m field of the SQLXCAXGRP.
The client then calls a stored procedure SYSIBM.SQLCAMESSAGE with the
SQLERRMSG_m value as a parameter to get the full localized message. A
non ascii separator is used as a token separator and used by the stored
procedure to separate the tokens.
In the server (DRDAConnThread) we have these separators.
byte[] sep = {20}; // use it as separator of sqlerrmc
tokens
byte[] errSep = {20, 20, 20}; // mark between exceptions
String separator = new String(";");
String errSeparator = new String(errSep);
The client normally just sends the full string back to the server, but
does have code to split up the tokens if it can't retrieve the message.
This code expects a byte value of -1 as a separator.
org.apache.derby.client.am.SQLca.java:
// non-delimiter - continue to write into buffer
if (tokenBytes[index] != -1) // -1 is the delimiter '\xFF'
Short term options include:
1) Send an ascii separator of some sort. (Is there some safe value
that would not be in the messages?)
2) Change the client to expect what the server is sending.
3) Change the server to send what the client is expecting.
I'm leaning toward 2 so as not to impose any risk for backward
compatibility or odbc or whatever. On the other hand I always thought
those separator values in the server were a bit weird. Does anyone have
any thoughts on this?
Kathey
