|<< Back to previous view|
[GLASSFISH-18596] Cannot find javadb client jar file, derby jdbc driver will not be available by default Created: 04/Apr/12 Updated: 14/Jun/13 Resolved: 07/Apr/12
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
Windows 7 - Eclipse Indigo
|Participants:||Sanjeeb Sahoo, tweety and Will Fardell|
Getting that warning when launching se client application
04-avr.-2012 12:31:36 com.sun.enterprise.v3.server.CommonClassLoaderServiceImpl findDerbyClient
|Comment by Sanjeeb Sahoo [ 07/Apr/12 06:49 PM ]|
This is not an issue. This message suggests that glassfish could not locate derby drivers in usual places. It searches for them in AS_DERBY_INSTALL/lib directory or in JAVA_HOME/db/lib. If you don't want to see the message, then make the driver available in one of those places.
|Comment by tweety [ 10/Apr/12 07:12 AM ]|
Thanks but I don't agree with you. I don't know very well glassfish and derby but ... Glassfish is installed in c:\glassfish3. And the derby drivers are in c:\glassfish3\javadb\lib. Right ?
Properties p = new Properties();
the new InitialContext(p); gives always gives me the warning message even if the db is started.
And using a process monitor application I can see the derby.jar and derbyclient.jar are read from javadb/lib
|Comment by Sanjeeb Sahoo [ 10/Apr/12 07:28 AM ]|
From your description so far, I see you are directly launching the SE client, i.e., without appclient script. So, I am pretty sure AS_DERBY_INSTALL system property is not set for you. In the absence of this property, our derby driver finder logic will try to find derby drivers in a dir obtained like this:
You can check if you have derby drivers available in such a place. If not, the warning is legitimate and we can't fix it. You can ask client container folks to see if they can set up appropriate properties when the system is bootstrapped via JNDI.
|Comment by tweety [ 10/Apr/12 08:16 AM ]|
Ok. I understand. I don't have any driver in the java_home directory and I don't have any AS_DERBY_INSTALL property.
|Comment by Sanjeeb Sahoo [ 10/Apr/12 08:24 AM ]|
I know why you are still getting it. It's because our code is not looking at System.getProperties or System.getenv. It is expecting the property to be set in a object called StartupContext which has not taken place because you are not using appclient script to launch the client. Either you make javadb available in JAVA_HOME or you file a bug against "app client container." AFAIK, we don't officially support embedding appclient container using JNDI yet, so they can turn the bug to an RFE or even close them. Just a warning. If you are still not clear, use glassfish users mailing list.
|Comment by Will Fardell [ 14/Jun/13 09:26 PM ]|
tweety this is probably too late for you but I was having the same problem with GlassFish 4 and JDK1.7.0_21. I thought I would post in case it is useful for someone else.
Looking at the findDerbyClient in CommonClassLoaderServiceImpl, it can locate Derby home in a couple of different ways, from the StartupContext or relative to the java.home System Property.
I was running in eclipse which by default runs apps using the JRE. DERBY can’t be found relative to the JRE's java.home. Switching to running under the JDK fixed this as it could find DERBY relative to the JDK’s java.home.
Before I realised this I traced it through and came up with a convoluted way of initializing the StartupContext for standalone clients. I certainly wouldn’t use this hack in production but it might be useful for other test scenarios.
Add the following imports:
Add the following code before you create the ProgrammaticLogin:
Properties properties = new Properties();
This might have some unforeseen side effects so use with caution.