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.
Set for installation: NB 6.0 + VisualWebPack + Glassfish v2 b38. Problem for VisualWebPack - Property "Java DB Location" gets incorrect value: if nondefault name of Glassfish directory for Glassfish installation path is used (for example, on WinXP "glassfish" instead of "glassfish-v2-b38"), a correct path for Glassfish databases will be changed to an incorrect JAVA_HOME path (for example, on WinXP wrong path "C:\Petrov\j2sdk1.6.0\db" is used instead of correct path "C:\glassfish\javadb").
pal127, Could you please attach installation log file? It is located at ~/.nbi/log (smth like "C:\Documents and Settings\<User>\.nbi\log\20070215001056.log").
Well... I guess you are speaking about NetBeans and Runtimes->Drivers->Java DB (Embedded) Am I right? In that case I can say that I`m not sure that it is NBI issue. I do think that it NetBeans issue of getting Database or, that is more probably, it is made by design. I`ve done the similar installation with using JDK5 and not JDK6 (both for NetBeans and GlassFish). The result is that proper JavaDB location is set for Java DB (Embedded). It points to GlassFish`s javadb subdir. I guess that it is set correctly because JavaDB is not embedded in JDK5. I`ve also tried to install Application Server (actually, 9.1 b40) with using JDK6, removed ~/.netbeans/dev, after NetBeans started I`ve manually added AppServer instance. After NetBeans restart I see that Java DB (Embedded), again, points to JDK`s derby not to the AppServer one. So.. in conclusion. I do think that JDK`s jars are loaded first so in case of JDK6 NetBeans gets jdk`s JavaDB first and then skip GlassFish`s one. In case of JDK5 the only JavaDB driver is get from GF. And that is what you need. I`m reassinging for db component for the further work and raising the priority for (I hope) more quick evaluation.
Created attachment 39810 [details] Log for installation
Yes, dlipin, I think your explanation of this bug reason is absolutely right. I've attached an installation log-file (j2sdk1.6.0 was used).
I can reproduce. Back to P2, since the user impact is low. Also note that more quick evaluation is not a reason for increasing the priority.
Thanks for the time spent on evaluating this. The behavior is almost as designed. On JDK 1.6 the Java DB instance bundled with JDK should be registered instead of the one bundled with GlassFish. I made some changes to ensure that this is always true. Checking in nbproject/project.xml; /cvs/db/derby/nbproject/project.xml,v <-- project.xml new revision: 1.14; previous revision: 1.13 done Checking in src/org/netbeans/modules/derby/DerbyOptions.java; /cvs/db/derby/src/org/netbeans/modules/derby/DerbyOptions.java,v <-- DerbyOptions.java new revision: 1.14; previous revision: 1.13 done Checking in src/org/netbeans/modules/derby/Installer.java; /cvs/db/derby/src/org/netbeans/modules/derby/Installer.java,v <-- Installer.java new revision: 1.4; previous revision: 1.3 done RCS file: /cvs/db/derby/src/org/netbeans/modules/derby/JDKDerbyHelper.java,v done Checking in src/org/netbeans/modules/derby/JDKDerbyHelper.java; /cvs/db/derby/src/org/netbeans/modules/derby/JDKDerbyHelper.java,v <-- JDKDerbyHelper.java initial revision: 1.1 done Checking in src/org/netbeans/modules/derby/spi/support/DerbySupport.java; /cvs/db/derby/src/org/netbeans/modules/derby/spi/support/DerbySupport.java,v <-- DerbySupport.java new revision: 1.12; previous revision: 1.11 done
Verified - not reproduced on NB 6.0 M9 build #070425000