[
https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294314#comment-16294314
]
Rick Hillegas commented on DERBY-6945:
--------------------------------------
Responding to the following question, posed by Bryan in email to derby-dev:
"What sort of changes were necessary to the tests? Do these changes indicate
any areas where Derby applications themselves may need to make similar
changes?" In particular, Bryan wanted more detail on this part of the commit
comment:
"
M
java/testing/org/apache/derbyTesting/functionTests/harness/FileCompare.java
M
java/testing/org/apache/derbyTesting/functionTests/tests/tools/SysinfoLocaleTest.java
M java/testing/org/apache/derbyTesting/junit/SecurityManagerSetup.java
M java/testing/org/apache/derbyTesting/junit/TestConfiguration.java
Adjust tests to account for changes made to the product.
"
Thanks for helping me think through this jigsaw transition, Bryan.
Here is some more explanation for those changes. Detailed diffs are at the end
of this comment.
1) FileCompare - A small change was made to account for the changes made to
ProductGenusNames. That file is an internal file which is not part of Derby's
external api. Applications should not reference that file and therefore should
not be affected by this change.
2) SysinfoLocaleTest - derbyshared.jar was added to the classpath constructed
by this test. This is a necessary consequence of placing the shared code in its
own jar file. This DOES affect Derby users and applications. The release notes
for 10.15 will need to tell users to put derbyshared.jar on their classpaths.
3) SecurityManagerSetup - A method header comment was changed, notifying the
reader that derbyshared.jar needs to be on the classpath. This change will not
affect applications.
4) TestConfiguration - A call to lookup the absolute pathname of the test run's
system directory was placed in a privileged block. I confess, I don't know why
this worked before without the privileged block. The failure occurred in
AssertFailureTest.testAssertFailureThreadDump(), a test which stresses the
ability of Derby assertion machinery to retrieve stack traces. That machinery
is not exercised by Derby applications. Since I don't fully understand why the
change was necessary, there may indeed by an unknown affect on applications.
But I wrote this off as an artifact of our complicated test setup.
--- java/testing/org/apache/derbyTesting/functionTests/harness/FileCompare.java
(revision 1817657)
+++ java/testing/org/apache/derbyTesting/functionTests/harness/FileCompare.java
(working copy)
@@ -33,6 +33,8 @@
import java.util.StringTokenizer;
import java.util.Properties;
+import org.apache.derby.iapi.services.info.ProductGenusNames;
+
public class FileCompare
{
@@ -109,7 +111,7 @@
else {
// if this is using product jars, use product_master
first
Class c = FileCompare.class; // get our class loader
- InputStream is =
c.getResourceAsStream("/org/apache/derby/info/DBMS.properties");
+ InputStream is = c.getResourceAsStream("/" +
ProductGenusNames.DBMS_INFO);
Properties dbprop = new Properties();
dbprop.load(is);
is.close();
Index:
java/testing/org/apache/derbyTesting/functionTests/tests/tools/SysinfoLocaleTest.java
===================================================================
---
java/testing/org/apache/derbyTesting/functionTests/tests/tools/SysinfoLocaleTest.java
(revision 1817657)
+++
java/testing/org/apache/derbyTesting/functionTests/tests/tools/SysinfoLocaleTest.java
(working copy)
@@ -159,12 +159,13 @@
private static void runSysinfo() throws Exception {
final String className = "org.apache.derby.tools.sysinfo";
URL sysinfoURL = SecurityManagerSetup.getURL(className);
+ URL derbysharedURL =
SecurityManagerSetup.getURL("org.apache.derby.shared.common.i18n.MessageUtil");
URL emmaURL = getEmmaJar();
URL[] urls = null;
if(emmaURL != null) {
- urls = new URL[] { sysinfoURL, emmaURL };
+ urls = new URL[] { sysinfoURL, derbysharedURL, emmaURL };
} else {
- urls = new URL[] { sysinfoURL };
+ urls = new URL[] { sysinfoURL, derbysharedURL };
}
// Create a new class loader that loads the Derby classes afresh.
Index: java/testing/org/apache/derbyTesting/junit/SecurityManagerSetup.java
===================================================================
--- java/testing/org/apache/derbyTesting/junit/SecurityManagerSetup.java
(revision 1817657)
+++ java/testing/org/apache/derbyTesting/junit/SecurityManagerSetup.java
(working copy)
@@ -334,7 +334,7 @@
* <P>
* Jar files:
* <BR>
- * derbyTesting.codejar - URL of derby.jar,
+ * derbyTesting.codejar - URL of derby.jar, derbyshared.jar,
* derbynet.jar and derbytools.jar, all assumed to be in the
* same location.
* <BR>
Index: java/testing/org/apache/derbyTesting/junit/TestConfiguration.java
===================================================================
--- java/testing/org/apache/derbyTesting/junit/TestConfiguration.java
(revision 1817657)
+++ java/testing/org/apache/derbyTesting/junit/TestConfiguration.java
(working copy)
@@ -38,6 +38,8 @@
import junit.framework.Test;
import junit.framework.TestCase;
+import org.apache.derbyTesting.functionTests.util.PrivilegedFileOpsForTests;
+
/**
* Class which holds information about the configuration of a Test.
*
@@ -154,8 +156,10 @@
final File dsh = new File("system");
+ String absolutePath = PrivilegedFileOpsForTests.getAbsolutePath(dsh);
+
BaseTestCase.setSystemProperty(
- "derby.system.home", dsh.getAbsolutePath());
+ "derby.system.home", absolutePath);
}
/**
> Re-package Derby as a collection of jigsaw modules
> --------------------------------------------------
>
> Key: DERBY-6945
> URL: https://issues.apache.org/jira/browse/DERBY-6945
> Project: Derby
> Issue Type: Improvement
> Affects Versions: 10.13.1.2
> Reporter: Rick Hillegas
> Attachments: derby-6945-01-aa-remove_derbyPreBuild_dep.diff,
> derby-6945-02-ab-newDerbySharedJar.diff, jdeps.out.tar
>
>
> Once we commit to building with Java 9 (see DERBY-6856), we should consider
> re-packaging Derby as a set of jigsaw modules. This would result in a
> different set of release artifacts. This might be a good opportunity to
> address the Tomcat artifactory issues raised by issue DERBY-6944.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
