OK, that didn't work. I think I need to devise a separate test. Maybe
I'll just call the EncryptionManager constructor directly :)
David
Sunitha Kambhampati (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1117?page=comments#action_12370630 ]
Sunitha Kambhampati commented on DERBY-1117:
--------------------------------------------
Hi David, I dont have a testcase available, but I found this when I was debugging when I was doing some other fix.
The codepath which lead to this was an exception in org.apache.derby.client.am.EncryptionManager.constructor.
But maybe if you run the derbynet/testSecMec.java test in DerbyNetClient
framework, with your change, the master file may change..(?).
Thanks.
SQLException can lose stacktrace in some cases.
------------------------------------------------
Key: DERBY-1117
URL: http://issues.apache.org/jira/browse/DERBY-1117
Project: Derby
Type: Bug
Components: Network Client
Versions: 10.2.0.0
Reporter: Sunitha Kambhampati
Assignee: David Van Couvering
Priority: Minor
Fix For: 10.2.0.0
cause is being lost in the following constructor in SqlException
public SqlException(LogWriter logwriter,
MessageId msgid, Object[] args, Throwable cause)
{
this(
logwriter,
msgutil_.getCompleteMessage(
msgid.msgid,
args),
ExceptionUtil.getSQLStateFromIdentifier(msgid.msgid),
ExceptionUtil.getSeverityFromIdentifier(msgid.msgid));
}
maybe we should add setThrowable(cause) so we dont lose track of it.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
