[ http://issues.apache.org/jira/browse/DERBY-901?page=all ]
Sunitha Kambhampati updated DERBY-901:
--------------------------------------
Attachment: Derby901.p1.diff.txt
Derby901.p1.stat.txt
TestEnc.java
This fix (Derby901.p1.diff.txt and Derby901.p1.stat.txt ) fixes the usage of
default String encoding in NetworkServer error message delimiters.
SQLERRMC_TOKEN_DELIMITER and SQLERRMC_MESSAGE_DELIMITER
Overview:
--The server sends the sqlerrmc which includes the following for each message
if there are multiple messages in the exception:
message arguments for the error + SQLERRMC_TOKEN_DELIMITER + messageId. see
DRDAConnThread.buildTokenizedSqlerrmc.
--Server sends the sqlerrmc using UTF8 encoding to the client.To get the
message, client sends back information to the server calling
SYSIBM.SQLCAMESSAGE (see Sqlca.getMessage). Several parameters are sent to
this procedure including the locale, the sqlerrmc that the client received from
the server.
On server side, the procedure SQLCAMESSAGE in SystemProcedures then calls the
MessageService.getLocalizedMessage to retrieve the localized error message.
In MessageService.getLocalizedMessage the sqlerrmc that is passed in, is parsed
to retrieve the message id. The value it uses to parse the MessageId is char
value of 20, otherwise it uses the entire sqlerrmc as the message id.
Problem:
Because the SQLERRMC_TOKEN_DELIMITER in DRDAConnThread was not portable, the
bytes would be converted to string using native encoding. Therefore localized
error messages would not be obtained correctly from the server and thus error
messages on client would be displaying the sqlerrmc values.
E.g of the problems caused by SQLERRMC_TOKEN_DELIMITER
String SQLERRMC_TOKEN_DELIMITER = new String(new byte[] {20});
I wrote a small program to see what the value would map to in different
encoding's.
Cp1047 is encoding on Z/os.
*************************
ENCODING USED Cp1047
=====================
[0]?=157
*************************
ENCODING USED UTF-16
=====================
[0]?=65533
*************************
ENCODING USED UTF-8
=====================
[0]=20
*************************
ENCODING USED US-ASCII
=====================
[0]=20
This fixes
- SQLERRMC_TOKEN_DELIMITER, SQLERRMC_MESSAGE_DELIMITER and the corresponding
usage of it in SystemProcedures to not use the default string constructors that
are non portable.
Testing:
- derbyall ran ok on ibm142/linux.
- derbynetclientmats and derbynetmats were run on Z/os platform and the error
message garbled diffs have all been resolved there. There are still failures on
z/os that will need to be resolved.
Simulate Testing on Windows:
- Sun JVM1.5, Start server with UTF-16 encoding as
java -cp "C:/workghm/svnclient/trunk2/classes" -Dfile.encoding=UTF-16
-Dconsole.encoding=Cp1252 org.apache.derby.drda.NetworkServerControl start
- Run the standalone repro.
java -cp ".;C:/workghm/svnclient/trunk2/classes;." -Dfile.encoding=UTF8
-DConsole.encoding=Cp1252 TestEnc
WITHOUT FIX
==========================================================================
$java -cp ".;C:/workghm/svnclient/trunk2/classes;." -Dfile.encoding=UTF8
-DConsole.encoding=Cp1252 TestEnc
Initializing connection type: derbynetclient
driver: org.apache.derby.jdbc.ClientDriver
url:
jdbc:derby://localhost:1527/wombatderbynetclient;create=true;traceFile=derbynetclient.trace
Obtaining the connection
Database: Apache Derby 10.2.0.0 alpha
lnDriver: Apache Derby Network Client JDBC Driver 10.2.0.0 alphae=Encountered
"<EOF>" at line 1, column 10�42X01
Note: the message is Encountered "<EOF>" at line 1, column 10�42X01
==========================================================================
WITH FIX
$java -cp ".;C:/workghm/svnclient/trunk2/classes;." -Dfile.encoding=UTF8
-DConsole.encoding=Cp1252 TestEnc
Initializing connection type: derbynetclient
driver: org.apache.derby.jdbc.ClientDriver
url:
jdbc:derby://localhost:1527/wombatderbynetclient;create=true;traceFile=derbynetclient.trace
Obtaining the connection
Database: Apache Derby 10.2.0.0 alpha
lnDriver: Apache Derby Network Client JDBC Driver 10.2.0.0 alphae=Syntax error:
Encountered "<EOF>" at line 1, column 10.
Note: The error message is correctly retrived as
Syntax error: Encountered "<EOF>" at line 1, column 10.
=======================
Can someone please review/commit this change if it looks ok. Thanks.
It might be nice to add some tests with server running with different encoding.
I'll see if we can do that.
> Remove use of String(byte[]) constructors in network server leading to
> non-portable behaviour
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-901
> URL: http://issues.apache.org/jira/browse/DERBY-901
> Project: Derby
> Type: Bug
> Components: Network Server
> Reporter: Daniel John Debrunner
> Assignee: Sunitha Kambhampati
> Attachments: Derby901.p1.diff.txt, Derby901.p1.stat.txt, TestEnc.java
>
> These constructors use the Java default platform encoding to convert the
> bytes to a String, this typically leads to bugs on platforms with different
> encodings.
> Replace with code using fixed conversion, or alternative mechanisms.
> If the call is required its use should be commented as to why it is required.
> org.apache.derby.impl.drda.DRDAConnThread
> I generated this list using the Java search in eclipse for references to the
> constructors
> String(byte[])
> String(byte[],int,int) - no occurences found in java/drda
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
