db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BeNdErR <bendertheoffender...@hotmail.com>
Subject Re: Derby : No suitable driver found for jdbc:derby:db;create=true
Date Tue, 07 Dec 2010 17:28:34 GMT

I'm quoting this message from Bryan, that replyed in another thread due to
post pending in this thread. I preferred to reply here for the context of
the argument.

(this is the link of the other thread:

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.

View raw message