<< 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

Status: Resolved
Project: glassfish
Component/s: classloader
Affects Version/s: 3.1.2_b23
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: tweety Assignee: Sanjeeb Sahoo
Resolution: Invalid Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 - Eclipse Indigo


Tags:
Participants: Sanjeeb Sahoo, tweety and Will Fardell

 Description   

Getting that warning when launching se client application

04-avr.-2012 12:31:36 com.sun.enterprise.v3.server.CommonClassLoaderServiceImpl findDerbyClient
INFO: Cannot find javadb client jar file, derby jdbc driver will not be available by default.



 Comments   
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 ?
I can do asadmin start-database.
In my application :

Properties p = new Properties();
p.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory");
p.setProperty("java.naming.provider.url", "localhost:3700");
Context context = new InitialContext(p);

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:
new File(new File(System.getProperty("java.home")), "../db/lib");

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.
But now it is fixed (property set).
In my client
System.out.println(System.getenv("AS_DERBY_INSTALL"));
gives me
c:\glassfish3\javadb
but still same warning. And the process monitor still tells me it's searching (and finding) driver in the c:\glassfish3\javadb and anywhere else.
And I don't understand "You can ask client container folks to see if they can set up appropriate properties when the system is bootstrapped via JNDI." You can give me more details ?
Thanks.

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:

import com.sun.enterprise.module.ModulesRegistry;
import com.sun.enterprise.module.bootstrap.StartupContext;
import com.sun.enterprise.module.single.StaticModulesRegistry;

Add the following code before you create the ProgrammaticLogin:

Properties properties = new Properties();
properties.setProperty("AS_DERBY_INSTALL", "C:/glassfish4/javadb"); // assuming default location
ModulesRegistry modulesRegistry = new StaticModulesRegistry(Globals.class.getClassLoader(), new StartupContext(properties));
Globals.setDefaultHabitat(modulesRegistry.createServiceLocator("default"));

This might have some unforeseen side effects so use with caution.

Generated at Fri Apr 18 11:19:37 UTC 2014 using JIRA 4.0.2#472.