Re: [jira] Commented: (DERBY-930) Add support for autoloading of Derby client drivers
Hi Bryan, Thanks for the quick response. I have revised the release note. Hopefully, it now describes the VM-specific issues better. Regards, -Rick Bryan Pendleton wrote: Rick Hillegas (JIRA) wrote: Adding a release note for this issue: Hi Rick, thanks for writing the release note. It wasn't clear to me from reading the release note whether this issue only affects JDK 1.6 environments, or whether it can arise under older VMs as well. If it only affects JDK 1.6 environments, perhaps we could change the release note to read: If an embedded Derby application runs in a JDK 1.6/JDBC4 environment, and generates its own Derby properties on the fly, and... thanks, bryan
Re: [jira] Commented: (DERBY-930) Add support for autoloading of Derby client drivers
Rick Hillegas (JIRA) wrote: I think that derby-dev should continue to discuss the issue which Olav has analyzed in DERBY-1399. I will continue this discussion shortly. If the behaviour change for DERBY-930 is intentional a special release note is needed for this issue in the section for Changes that might affect existing applications: It might read something like this ... PROBLEM: Autoloading of driver causes changes to behavior of derby properties. SYMPTOM: Derby does not recognize derby.system.home or other properties set by the application and creates database in the wrong location or fails to recognize properties. CAUSE: Automatic loading of the driver with JDBC 4.0 causes derby to be booted before the derby.system.home property has been set. Therefore the property is ignored. SOLUTION: There is no product solution to this issue. WORKAROUND: The only workaround is to set derby.system.home before any connection is made to any database. For example derby.system.home can be specified on the command line with -Dderby.system.home=location Now that I put it like that I can imagine all the users in the world that this is going to impact and I become more convinced that this is a bug and a serious regression.I liked the suggestion to defer booting derby embedded until the first embedded connection is made, but apparently there are other implications for derby.drda.startNetworkServer that I don't quite understand yet. IMHO they all should be fixed if possible so we don't break existing applications. Kathey
