I'm quoting this message from Bryan, that replyed in another thread due to post pending in this thread. I preferred to answer here for the context of the argument.
(this is the link of the other thread: http://old.nabble.com/Derby%3A-SQL-ERROR--%3E-Encountered-%22CASCADE%22-at-line-xyz-td30366617.html#a30398400) Bryan Pendleton-3 wrote: > > I'm not sure. That problem is really odd. I think that Kristian's theory > about classloaders is the most likely, as application servers and RMI > runtimes > tend to provide really finicky class loading behaviors. Since you've > demonstrated > that the simple "java -classpath ..." command can successfully load and > run > Derby, you've obviously got a valid copy of the Derby jar files, and > you've > obviously set the classpath correctly to point at those jars, which > normally > is all you need to do. > > So something in your server code must be interfering with the > Class.forName() > behavior, which as I noted above is not uncommon with complex server > runtimes. > > For example, some application servers have security constraints in their > class loading behaviors, and won't allow application code to load > arbitrary > libraries without configuring the server's security system to allow the > library loading. > > Class.forName() is a base JDK call, not a Derby call, so I'm afraid > that you're going to need to seek help from your server provider. Did you > write this server code yourself, or is it a well-known server of some > type? > > The only other things I can think to try are: > 1) see if your JDK has any additional diagnostic flags you can run; for > example I think the Sun JDK provides a "java -verbose:class" flag that > might give you more clues about the class-loading activity. > 2) see if you can find a powerful Java debugger, and run your server under > the Java debugger, and break at the point where you're about to do the > Class.forName call, and see if your debugger has any tools to diagnose the > ClassNotFoundException; for example I think you can load the Sun JDK > source.zip > for the Sun Java runtime sources, and possibly your debugger will then > allow > you to step through the Class.forName call and see if you can spot why > it's failing. > > thanks, > > bryan > as you can read in my penultimate post, I found the right configuration. It was (probably) a problem with the activatable server, as bryan said too. But now that's working, I've another question for you: My app is made of a login-server connected with embeddeddriver to the derby, and another server that needs to connect too to the database. Reading derby manual, I found I need to use ClientDriver, to avoid the "maybe someone is already connected to the db" (in this case, the login-server) message. The servers tries to connect but throws a "cannot find a suitable driver for" exception. The question is: if, for the login srv, I use 'jdbc:derby:/path/db/;create=true' as the connection url the driver manager connects to (with embeddedDriver), do I have to use the same connection url for the client driver? Do I have to specify the user (APP as default) and the password (I can't find out how to set a new pass, the default seems to be empty reading derby tutorials)? Do I have to run the derby-server before I start my entire application and then connect with something like 'jdbc:derby://localhost:port/dbname;blahblahblah' for both my servers? thanks in advance, I hope you understand what I said :D -- View this message in context: http://old.nabble.com/Derby-%3A-No-suitable-driver-found-for-jdbc%3Aderby%3Adb-create%3Dtrue-tp30335341p30398519.html Sent from the Apache Derby Users mailing list archive at Nabble.com.
