[ http://issues.apache.org/jira/browse/DERBY-1399?page=comments#action_12416359 ]
Olav Sandstaa commented on DERBY-1399: -------------------------------------- Comments to Kathey's concerns about this patch (or rather the change introduced in DERBY-930): Autoloading of JDBC drivers is a new feature required by JDBC4. In addition to the support for autoloading added to JDBC4 in DERBY-930, the main change is in how new JVMs confirming to Java SE 1.6 treat JDBC4 drivers. So this test change has just as much with adjusting to new behavior in how JVMs loads drivers as it has to do with the changes added to Derby in DERBY-930. I have raised my opinion about support for autoloading of JDBC drivers in a different mail thread (personally I do not like automagic things to happen behind my back even if it is considered "ease of development"), see: http://www.nabble.com/Autoloading-of-JDBC-drivers-considered-harmful--t1689676.html) Still, autoloading will be a documented and supported feature in Derby 10.2 (at least it seems so) and in Java SE 1.6, and (to quote from one of the emails in this email thread) "Thus this is fully documented behavior that any application developer must understand." So as long as the embedded Derby driver is loading the Derby engine and in some cases also the network server, autoloading of the embedded JDBC driver may require applications (and Derby tests) to take this into account when upgrading to a 1.6. JVM. This is basically what the patch I have suggested do. There could have been other solutions to this problem by doing changes to Derby. For instance splitting loading of the embedded driver and booting of the Derby engine and starting of the network server. Even if we decided to do this, this test had to be changed in one way or the other in order to get the network server started (it is now started by setting the property derby.drda.startNetworkServer=true before the embedded driver is loaded). I think splitting of driver loading and booting of the engine would be a good thing to implement, but right now I do not have the time to take on this task. My itch right now is to get this test to run with JDK 1.6 and the change is basically to take into account the new behavior that any 1.6 JVM will have. > DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver > autoloading > ----------------------------------------------------------------------------------- > > Key: DERBY-1399 > URL: http://issues.apache.org/jira/browse/DERBY-1399 > Project: Derby > Type: Bug > Components: Test > Versions: 10.2.0.0 > Environment: Sun JDK 1.6 > Reporter: Olav Sandstaa > Assignee: Olav Sandstaa > Priority: Minor > Attachments: autoload.diff > > DerbyNetAutoStart.java fails when running on JDK 1.6 with DerbyNet and > DerbyClient frameworks with the following error: > Starting test case 1. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 152 > 7 with message Connection refused. > Starting test case 2. > Could not access database through the network server. > java.net.ConnectException : Error connecting to server localhost on port > 314 > 15 with message Connection refused. > Starting test case 3. > Starting test case 4. > Starting test case 5. > FAILED. > This test seems to have failed consistently since JDBC4 driver autoloading > was introduced (see DERBY-930). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
