It's hard to say what's going on, but the instability in your
experiments is hard to reconcile against the deterministic code paths
involved in JDBC autoloading.
I can only speculate about what is causing this instability:
1) What JDBC URLs does your MockDriver claim to support?
2) Is something tricky being done to the classpath, creating a situation
in which the Derby jars are not visible when you invoke
DriverManager.getConnection()?
3) What happens when you do a
Class.forName("org.apache.derby.jdbc.EmbeddedDriver")? What are the
chain of errors raised? For the record, this is the recommended JDBC way
to fault in a driver which was missed at autoloading time. Autoloading
occurs on the very first call to DriverManager.getConnection() during
the lifetime of the JVM.
Hope this helps,
-Rick
On 7/8/20 10:37 AM, Russell Bateman wrote:
...again, don't know what I changed.* I'm only depending on
/derby-10.15.2.0.jar/.
What I think is going on is an artifact of being side-by-side with
another JDBC driver implementation.
I was hoping to keep the original mocked test driver working alongside
the Derby implementation at least until I'm able to abolish it in
every case. Just as used to be the case, it's registered thus:
DriverManager.registerDriver( new MockDriver() );
However, this is not how it works for Derby. It just happens on the
basis of having the JAR linked (in /pom.xml/). The problem comes that,
because the MockDriveris explicitly registered, when we go to create a
Derby connection:
java.sql.Connection connection = DriverManager.getConnection(
"jdbc:derby:memory:sampledb;create=true" );
...DriverManagertakes as license to create an instance of the old test
mock because that is the (only) driver in its registeredDriverslist.
*I moved the Derby-based code out of the same Java package to solve this?
Thanks again. I'm sorry for having made this annoying.
Russ
