This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The "New JDBC Driver" wizard selects the incorrect OracleDriver class. For JDK 1.4 and above, the class at oracle.jdbc.driver.OracleDriver is no longer the recommended driver class, and its use is now being discouraged. The current recommended driver class is oracle.jdbc.OracleDriver (which extends oracle.jdbc.driver.OracleDriver). Further, the wizard doesn't include oracle.jdbc.OracleDriver in the drop-down list of available drivers and the "Find" operation won't locate it, even though it does implement java.sql.Driver (by inheritance). The driver class name can be manually typed into the field, but the "New Database Connection" wizard won't populate the "Database URL" field with the driver url syntax. The work around is simple enough--just a little extra typing. But it's probably about time these wizards were updated.
I am pretty sure that the bug with 'Find' is that oracle.jdbc.OracleDriver extends oracle.jdbc.driver.OracleDriver, which implements java.sql.Driver. Our code only tests to see if the *current* class implements java.sql.Driver, and doesn't check super classes. I'll work on fixing this logic and see if that solves the problem.
Find needs to be fixed too, but that won't solve the problem entirely. When you open the dialog, it will still prefer the old driver class. See DriverListUtil and its usages.
Checked in fix. I used reflection with a specialized classloader (that includes the jar file in its search path) rather than JarFile operations to look for classes that implement java.sql.Driver.
I think you need to put all jars in the class loader at once. Otherwise you can have e.g. A.jar containing "ADriverImpl implements Driver" and B.jar containing "BDriver extends ADriverImpl". BDriver is the class that the user wants. The current solution will probably throw a ClassNotFoundException when analyzing BDriver. Some nitpicks: The "logger" field should probably be "LOGGER". Suggest logging the exceptions in isDriverClass() with a WARNING level, not FINE. Otherwise you can lose the stack trace of a random exception. You can then log both the exception and the message with a single log() call. The check for null in isDriverClass() seems superfluous. ClassLoader.loadClass() either loads and returns the class or throws an exception. Or am I missing something? Any particular reason to use "java.sql.Driver", e.g., the fully-qualified name? Missing commit log.
Thanks for reviewing, Andrei. > I think you need to put all jars in the class loader at once. Otherwise you can have e.g. A.jar containing "ADriverImpl > implements Driver" and B.jar containing "BDriver extends ADriverImpl". BDriver is the class that the user wants. The > current solution will probably throw a ClassNotFoundException when analyzing BDriver. Yes, thanks, good point, I will fix Some nitpicks: > The "logger" field should probably be "LOGGER". OK. I'm assuming that's a coding standard: static finals should be all caps, right? > Suggest logging the exceptions in isDriverClass() with a WARNING level, > not FINE. Otherwise you can lose the stack trace of a random exception. > You can then log both the exception and the > message with a single log() call. I thought we didn't want to overwhelm the log with too many stack traces. When I read the document on logging it seemed to suggest that these kinds of exceptions that don't have a big impact on behavior should be logged at a FINE level. > The check for null in isDriverClass() seems superfluous. ClassLoader.loadClass() either loads and > returns the class or throws an exception. Or am I missing something? I'm just being careful. I could turn it into an assert... > Any particular reason to use "java.sql.Driver", e.g., the fully-qualified name? No, I can fix that. > Missing commit log. OK, I didn't know about that standard, I'll start doing that.
> I'm assuming that's a coding standard: static finals should be all caps, right? Dont'get me started about coding standards :-) But note there is a "private static final String *BUNDLE*" declaration just above your logger declaration. It is always good to try to be consistent with the standard of the file you are modifying. > I thought we didn't want to overwhelm the log with too many stack traces. We don't. But this exception shouldn't be thrown often, if at all, to begin with. You are loading a class that you *know* is in that archive. So if an exception is thrown, then likely something went very wrong and you need to know about it. And if you log the stack trace and the reported of the issue attaches the message log you have all the information you need at hand. Otherwise you would need to tell the reporter how to enable the FINE messages, reproduce the issue again and re-attach the message log. > I'm just being careful. I could turn it into an assert... IMHO no need to be careful about a method in the platform which does not state it can return null. But if you really want to, then yes, please just use an assert. Thanks for working on this.
Checked in new revision based on Andrei's changes Checking in AddDriverDialog.java; /cvs/db/src/org/netbeans/modules/db/explorer/dlg/AddDriverDialog.java,v <-- AddDriverDialog.java new revision: 1.40; previous revision: 1.39 done
Andrei, I checked in changes based on your recommendation, but I am a little concerned, because with my tests, Oracle generates about five different stack traces and Java DB generates about three. I am worried that this is a little too much information... But I think more information is better than too little, and it's not like this is happening every second and will fill up the log file...
Updated to use toArray(Object[]) Checking in AddDriverDialog.java; /cvs/db/src/org/netbeans/modules/db/explorer/dlg/AddDriverDialog.java,v <-- AddDriverDialog.java new revision: 1.41; previous revision: 1.40 done IDE: [7/19/07 12:46 PM] Committing Files finished
I didn't expect exceptions to be thrown so often. You are right the Add Driver dialog is not used very often. But feel free to change the level back to FINE if you want.
Fixed in 6.0 FCS, not 6.0 beta1
Apologies, this change was for another bug. I hate how issuezilla moves me to the next bug in my query list.