[
https://issues.apache.org/jira/browse/DERBY-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744946#action_12744946
]
Knut Anders Hatlen commented on DERBY-700:
------------------------------------------
I noticed this in the new test (ClassLoaderBootTest):
- it would be good to null out the three ClassLoader fields in tearDown() so
that the class loaders and the classes they have loaded can be garbage
collected (otherwise they'll stay in memory until the full JUnit run has
finished)
- the decorateSQL() method creates a table which is said to be used to test
export, but I don't see any code for testing export
- the test cases are wrapped in try {...} catch (SQLException se) {
dumpSQLException(se); }. Won't this prevent the reporting of the exception in
JUnit? Better to let the exceptions be thrown and handled by the framework?
- the methods getFileWhichLoadedClass(Class) and getURL(File) have no callers
> Derby does not prevent dual boot of database from different classloaders on
> Linux and Mac OS X
> ----------------------------------------------------------------------------------------------
>
> Key: DERBY-700
> URL: https://issues.apache.org/jira/browse/DERBY-700
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1,
> 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.4.1.3
> Environment: ava -version
> java version "1.4.2_08"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)
> also
> java version "1.5.0_19"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-b02-304)
> Java HotSpot(TM) Client VM (build 1.5.0_19-137, mixed mode, sharing)
> on Mac OS X 10.5.7.
> Reporter: Kathey Marsden
> Priority: Critical
> Attachments: derby-700-01-aa-catchOverlappingFileLockException.diff,
> derby-700-01-ab-catchOverlappingFileLockException.diff, DERBY-700.diff,
> DERBY-700.stat, derby-700_06_07_07_diff.txt, derby-700_06_07_07_stat.txt,
> derby-700_06_19_2007, derby-700_diff.txt, derby-700_stat.txt,
> DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff,
> DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat,
> derby-700_with_NPE_fix_diff.txt, derby-700_with_NPE_fix_stat.txt, derby.log,
> derby700_singleproperty_v1.diff, derby700_singleproperty_v1.stat,
> DualBootRepro.java, DualBootRepro.java, DualBootRepro2.zip,
> DualBootRepro_mutltithreaded.tar.bz2, releaseNote.html, releaseNote.html
>
>
> Derby does not prevent dual boot from two different classloaders on Linux and
> Mac OS X.
> To reproduce run the program DualBootRepro with no derby jars in your
> classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can
> change the location by changing the DERBY_LIB_DIR variable.
> On Linux the output is:
> $java -cp . DualBootRepro
> Loading derby from file:10.1.2.1/derby.jar
> 10.1.2.1/derby.jar
> Booted database in loader java.net.urlclassloa...@8ed465
> FAIL: Booted database in 2nd loader java.net.urlclassloa...@dc6a77
> On Windows I get the expected output.
> $ java -cp . DualBootRepro
> Loading derby from file:10.1.2.1/derby.jar
> 10.1.2.1/derby.jar
> Booted database in loader java.net.urlclassloa...@1ac04e8
> PASS: Expected exception for dualboot:Another instance of Derby may have
> already booted the database D:\marsden\repro\dualboot\mydb.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
