Investigate using the standard java.net.URLClassLoader for database class loading.

• Key: DERBY-538
• Type: Sub-task
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Daniel John Debrunner
• Reporter: Daniel John Debrunner
• Component/s: Services
• Fix Version/s: 10.3.1.4

Description

Would change the fix for DERBY-537) so that's why it is a sub-task.
Use of the standard class loader would reduce security concerns and allow jars stored in the database to take advantage of standard features such as package sealing.

Comments

[Daniel John Debrunner]

Possible blocks DERBY-538, during some tests with my changes for 538 backups are failing due to the JarClassLoader keeping the jar file open of the shutdown database. So something is keeping a reference to database objects, haven't investigated it yet.

[Daniel John Debrunner]

Java bug 4950148 means that the closing of the jar file opened by URClassLoader is delayed until that object's GC, which can cause issues for tests which try to cleanup after a database shutdown.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4950148

Seem to hit this bug if I use this class loader, also seen in DatabaseClassLoadingTest for the testDatabaseInClasspath() which uses URLClassLoader. Once the test is complete and the database shutdown, the jar file cannot be removed from the file system on windows. Need to inviestigate more as to what is going on.

[Daniel John Debrunner]

Due to issues with the standard URLClassLoader I decided to continue with Derby's own JarLoader but extend it from SecureClassLoader.
This then will allow Derby's class loader to implement features such as package sealing.
Commit 543524 switched the parent class. Believe there is no more work to do under this issue.
Sealing and other security features can be added separately.