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.
Build: NetBeans IDE Dev (Build 201111080600) VM: Java HotSpot(TM) 64-Bit Server VM, 20.1-b02-383, Java(TM) SE Runtime Environment, 1.6.0_26-b03-383-11A511 OS: Mac OS X User Comments: musilt2: invoked view data on javadb SYS.SYSALIASES Stacktrace: java.lang.ClassNotFoundException: org.apache.derby.catalog.types.RoutineAliasInfo at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(AccessController.java:0) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Class.java:0)
Created attachment 113093 [details] stacktrace
Created attachment 129511 [details] Possible Fix The problem is that class org.apache.derby.catalog.types.RoutineAliasInfo can be found in JAR file derby.jar, but driver "Java DB (Network)" contains by default only file derbyclient.jar. The workaround is to add file derby.jar to the driver, using the "Customize JDBC Driver" dialog. Solution would be to show an informative text in the cells instead of throwing an exception. But, on the other side, it can make the problem more hidden. Please check the attached patch. Another solution is adding the second JAR file to the JDBC driver by default. The drawback is that is is useless for most users and it increases memory consumption. Matthias, Jirka, do you have any opinion? Thanks?
Honza suggested putting the error text to the cells and adding some sign (red exclamation mark) to the column header, or showing a notification dialog saying that there were some errors.
I would go for the second solution (adding the second necessary jar). Memory pressure is always critical, but in the long run I suspect more problems coming up, if the cell value is misused for error messages. For example the resulting DataViewTable at least would need to be set readonly, els the user could try to update with wrong values.
(In reply to comment #4) > I would go for the second solution (adding the second necessary jar). Memory > pressure is always critical, but in the long run I suspect more problems coming > up, if the cell value is misused for error messages. Good point, I agree. Fixed in http://hg.netbeans.org/core-main/rev/2c1bd76ed25c Thank you.
Integrated into 'main-golden', will be available in build *201301050001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/2c1bd76ed25c User: Jaroslav Havlin <jhavlin@netbeans.org> Log: #204942: Cannot find org.apache.derby.catalog.types.RoutineAliasInfo