Peter Neubauer wrote: > Hi Dan, > Thanks for the fast reply, > >>Applications should not acceess the Driver20 or Driver30 classes >>directly, the public api is EmbeddedDriver and DriverManager (e.g. >>DriverManager.getConnection). >> >>Driver20 and Driver30 do not handle the network URL, only the >>embedded, >>thus they are required in derby.jar. > > I understand that, but it seems that > "jdbc:derby://localhost:9001/journaldb;create=true" is returning the Driver30 > for client applications that have derby.jar in their classloader. I'm not > sure of the specification but maybe the problem is that from the > specification POV the embedded URL syntax "jdbc:derby:journaldb;create=true" > and the above new network client syntax are the same? > In that case there is a problem that might be surface not only for me, since > it seems that from the JDBC specification, the first driver accepting a given > connection URL has to be returned to the asking client. > > Not sure this makes sense, just want to stress the point that > http://www.solarmetric.com/Support/Newsgroups/news/article.php?id_article=%3Cde5ek5%24ecp%241%40solarmetric.netmar.com%3E&grp_id=1 > should not be able to happen since I used the network URL and you are saying > the Driver30 is only handling embedded URLs? > > /peter >
OK, I see the problem now. The acceptsURL() call for the Derby embedded drivers indicates it accepts jdbc:derby: which of course will incorrectly include jdbc:derby://. I thought this had been addressed, but obviously it wasn't. I'll enter a Jira bug. Dan.
