Alan Burlison <[EMAIL PROTECTED]> writes: > Knut Anders Hatlen wrote: > >> You shouldn't load the client driver unless your application uses >> jdbc:derby://localhost/mydb. The reason why the client driver seems to >> work in your case, is that the server already has loaded the embedded >> driver. So the code that runs inside the same JVM as the server should >> use jdbc:derby:mydb and not load the client driver, whereas the external >> scripts should load the client driver and use >> jdbc:derby://localhost/mydb. > > Unfortunately it's not that simple. If you use the embedded driver > with STRONG_PASSWORD_SUBSTITUTE_SECURITY & securityMechanism=8, you > get a NPE is you open, close and then reopen the database - which is > necessary if you want to be sure that the static database properties > you set are used.
OK, I think I see the problem now. It seems like if you connect to a database which has derby.connection.requireAuthentication=true using the embedded driver, Derby throws a NPE if the securityMechanism connection attribute is specified. Specifying the securityMechanism attribute for an embedded connection doesn't really make any sense, I think, since it says how to send passwords over a network connection, and the embedded driver doesn't use the network. This means you will have to connect without securityMechanism when you connect from within Tomcat (with the embedded driver), and with securityMechanism when you connect from the external scripts (with the client driver). Of course, you should have got an exception with a message explaining the problem, not a NPE. HTH, -- Knut Anders
