[
https://issues.apache.org/jira/browse/DERBY-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194367#comment-13194367
]
Myrna van Lunteren commented on DERBY-4785:
-------------------------------------------
Thank you for your continued interest in Derby!
I looked visually at the .diff file from the patch and I have the following
comments:
- a number of the tests have a *lot* of whitespace differences. In particular
is the case for the tests jdbcapi/HoldabilityTest.java,
jdbcapi/ConcurrencyTest.java, jdbcapi/DriverTest.java,
jdbcapi/BlobClob4BlobTest.java, jdbcapi/ProcedureTest.java.
It seems to me that you've reformatted those tests with a tab as the indent,
instead of the 4 spaces as per our formatting convention.
Typically, we do not touch code that we don't have to - it makes the diff huge,
and comparing the actual changes impractical.
- some of the tests that have only minimal changes still have unnecessary
whitespace changes, e.g.
jdbcapi/XATransactionTest.java. In fact, I don't see why that test needed to
be changed at all?
From the .diff file:
--------------------------
@@ -25,6 +25,7 @@
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
+
import java.sql.Statement;
import javax.sql.XAConnection;
import javax.sql.XADataSource;
@@ -426,6 +427,7 @@
assertEquals(XAException.XAER_RMFAIL, xae.errorCode);
}
}
+
/**
----------------------------
If there's no real reference to DB2Client or JCC here this file should get
svn revert-ed.
- A number of the changes remove the if clauses relating to DB2Client, but
leave the comments in place. The comments should go also. This is for instance
the case with lang/TableFunctionTest.java. From the .diff:
--------------------
{
// skip this test if using the DB2 client, which does not support the
// JDBC4 metadata calls.
- if ( usingDB2Client() ) { return; }
-
-
println( "\nExpecting correct function metadata from " +
functionName );
ResultSet rs = getFunctions( null, "APP",
functionName );
JDBC.assertFullResultSet( rs, expectedGetFunctionsResult, false );
---------------------
The comment lines '//skip this test if using the DB2 client, which does not
support the" and "// JDBC4 metadata calls." should also be removed.
Similar comments are in many of the other tests.
> Remove JCC tests and references to JCC in test code
> ---------------------------------------------------
>
> Key: DERBY-4785
> URL: https://issues.apache.org/jira/browse/DERBY-4785
> Project: Derby
> Issue Type: Sub-task
> Components: Test
> Affects Versions: 10.5.1.1, 10.6.1.0
> Reporter: Kathey Marsden
> Assignee: Jayaram Subramanian
> Priority: Minor
> Attachments: JCCRemovalStat_Feb182011.txt, JCCRemoval_Feb182011.txt,
> JCCRemoval_Jan112011.txt, JCC_Removal_DONOTCOMMIT_Dec29.txt,
> Stat_JCCRemoval_Jan112011.txt, d4785-compat-1a.diff, diff-jan172012.diff,
> jccremoval_Jan27.txt, jccremoval_stats_Jan27.txt, stat-jan172012.stat,
> stat_Dec29_JCC.txt
>
>
> I received a request to remove JCC testing from the derby suite. The user had
> a very old jcc version in their classpath 2.4 and 10.5 tests were failing
> with:
> com.ibm.db2.jcc.c.SqlException: DB2 SQL error: SQLCODE: -1, SQLSTATE: XJ040,
> SQLERRMC: Failed to start database
> '/results/axxon/58712/laka10a-derby-m101-20100830-003810/derbyall/derbynetmats/DerbyNet/derbynetmats/dblook_test_net_territory//wombat',
> see the next exception for details.::SQLSTATE: XJ001Java exception: 'Access
> denied (java.util.PropertyPermission com.ibm.crypto.provider.FIPSMODE read):
> java.security.AccessControlException'.
> at com.ibm.db2.jcc.c.o.a(o.java:3219)
> at com.ibm.db2.jcc.a.cb.q(cb.java:653)
> at com.ibm.db2.jcc.a.cb.p(cb.java:541)
> at com.ibm.db2.jcc.a.cb.l(cb.java:363)
> at com.ibm.db2.jcc.a.cb.d(cb.java:145)
> at com.ibm.db2.jcc.a.b.Sb(b.java:1274)
> at com.ibm.db2.jcc.a.b.a(b.java:1166)
> at com.ibm.db2.jcc.a.b.q(b.java:934)
> at com.ibm.db2.jcc.a.b.a(b.java:702)
> at com.ibm.db2.jcc.a.b.(b.java:305)
> at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:162)
> at java.sql.DriverManager.getConnection(DriverManager.java:322)
> at java.sql.DriverManager.getConnection(DriverManager.java:273)
> at org.apache.derby.tools.dblook.go(Unknown Source)
> at org.apache.derby.tools.dblook.(Unknown Source)
> at
> org.apache.derbyTesting.functionTests.tests.tools.dblook_test.lookThree(dblook_test.java:417)
> at
> org.apache.derbyTesting.functionTests.tests.tools.dblook_test.runTest(dblook_test.java:283)
> at
> org.apache.derbyTesting.functionTests.tests.derbynet.dblook_test_net_territory.doTest(dblook_test_net_territory.java:65)
> at
> org.apache.derbyTesting.functionTests.tests.derbynet.dblook_test_net_territory.main(dblook_test_net_territory.java:41)
> Now that I look at it more closely, their actual problem might be on the
> server side and JCC just reporting it but good to get the JCC tests out of
> the mix when people accidentally have it in their classpath anyway.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
