Rick Hillegas wrote: > > 1) Remove the JDBC4-driver-autoloading. This removes a useful > ease-of-development feature and makes us fail to be JDBC4-compliant. > > 2) Don't boot the engine when registering the embedded driver. Instead, > boot the engine the first time that someone requests an embedded > Connection. This approach involves a lot of testing.
I think it would be better if option 2 as described in the change in functional behaviour, not the implementation details (ie. engine booting). I think what is really proposed is: 10.1 (existing) - Derby reads system properties when its embedded driver is loaded. 10.2 (option 2) - Derby reads system properties when the first connection request is made to its embedded driver. Option 2 worries me a little because it can become less precise when the key system properties are read. E.g. what about a failed connection request, does that force the properties to be read? I think the goal should be to support auto-loading and to ensure applications that perform some setup and then explicitly load the Derby embedded driver continue to work. Dan. Dan.
