I am getting this message when I run my web application. It runs fine but I get this message during shutdown.
SEVERE: A web application registered the JBDC driver [oracle.jdbc.driver.OracleDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
Any help appreciated.
Since version 6.0.24, Tomcat ships with a memory leak detection feature, which in turn can lead to this kind of warning messages when there's a JDBC 4.0 compatible driver in the webapp's /WEB-INF/lib which auto-registers itself during webapp's startup using the ServiceLoader API, but which did not auto-deregister itself during webapp's shutdown. This message is purely informal, Tomcat has already taken the memory leak prevention action accordingly.
What can you do?
Ignore those warnings. Tomcat is doing its job right. The actual bug is in someone else's code (the JDBC driver in question), not in yours. Be happy that Tomcat did its job properly and wait until the JDBC driver vendor get it fixed so that you can upgrade the driver. On the other hand, you aren't supposed to drop a JDBC driver in webapp's /WEB-INF/lib, but only in server's /lib. If you still keep it in webapp's /WEB-INF/lib, then you should manually register and deregister it using a ServletContextListener.
Downgrade to Tomcat 6.0.23 or older so that you will not be bothered with those warnings. But it will silently keep leaking memory. Not sure if that's good to know after all. Those kind of memory leaks are one of the major causes behind OutOfMemoryError issues during Tomcat hotdeployments.
Move the JDBC driver to Tomcat's /lib folder and have a connection pooled datasource to manage the driver. Note that Tomcat's builtin DBCP does not deregister drivers properly on close. See also bug DBCP-322 which is closed as WONTFIX. You would rather like to replace DBCP by another connection pool which is doing its job better then DBCP. For example HikariCP or perhaps Tomcat JDBC Pool.
In your servlet context listener contextDestroyed() method, manually deregister the drivers:
// This manually deregisters JDBC driver, which prevents Tomcat 7 from complaining about memory leaks wrto this class
Enumeration<Driver> drivers = DriverManager.getDrivers();
while (drivers.hasMoreElements()) {
Driver driver = drivers.nextElement();
try {
DriverManager.deregisterDriver(driver);
LOG.log(Level.INFO, String.format("deregistering jdbc driver: %s", driver));
} catch (SQLException e) {
LOG.log(Level.SEVERE, String.format("Error deregistering driver %s", driver), e);
}
}
Although Tomcat does forcibly deregister the JDBC driver for you, it is nonetheless good practice to clean up all resources created by your webapp on context destruction in case you move to another servlet container which doesn't do the memory leak prevention checks that Tomcat does.
However, the methodology of blanket driver deregistration is dangerous. Some drivers returned by the DriverManager.getDrivers() method may have been loaded by the parent ClassLoader (i.e., the servlet container's classloader) not the webapp context's ClassLoader (e.g., they may be in the container's lib folder, not the webapp's, and therefore shared across the whole container). Deregistering these will affect any other webapps which may be using them (or even the container itself).
Therefore, one should check that the ClassLoader for each driver is the webapp's ClassLoader before deregistering it. So, in your ContextListener's contextDestroyed() method:
public final void contextDestroyed(ServletContextEvent sce) {
// ... First close any background tasks which may be using the DB ...
// ... Then close any DB connection pools ...
// Now deregister JDBC drivers in this context's ClassLoader:
// Get the webapp's ClassLoader
ClassLoader cl = Thread.currentThread().getContextClassLoader();
// Loop through all drivers
Enumeration<Driver> drivers = DriverManager.getDrivers();
while (drivers.hasMoreElements()) {
Driver driver = drivers.nextElement();
if (driver.getClass().getClassLoader() == cl) {
// This driver was registered by the webapp's ClassLoader, so deregister it:
try {
log.info("Deregistering JDBC driver {}", driver);
DriverManager.deregisterDriver(driver);
} catch (SQLException ex) {
log.error("Error deregistering JDBC driver {}", driver, ex);
}
} else {
// driver was not registered by the webapp's ClassLoader and may be in use elsewhere
log.trace("Not deregistering JDBC driver {} as it does not belong to this webapp's ClassLoader", driver);
}
}
}
I see this issue come up a lot. Yes, Tomcat 7 does automatically deregister it, but it that REALLY taking control of your code and a good coding practice? Surely YOU want to know that you have all the correct code in place to close all your objects, shut down database connection pool threads, and get rid of all warnings. I certainly do.
This is how I do it.
Step 1: Register a Listener
web.xml
<listener>
<listener-class>com.mysite.MySpecialListener</listener-class>
</listener>
Step 2: Implement the Listener
com.mysite.MySpecialListener.java
public class MySpecialListener implements ServletContextListener {
#Override
public void contextInitialized(ServletContextEvent sce) {
// On Application Startup, please…
// Usually I'll make a singleton in here, set up my pool, etc.
}
#Override
public void contextDestroyed(ServletContextEvent sce) {
// On Application Shutdown, please…
// 1. Go fetch that DataSource
Context initContext = new InitialContext();
Context envContext = (Context)initContext.lookup("java:/comp/env");
DataSource datasource = (DataSource)envContext.lookup("jdbc/database");
// 2. Deregister Driver
try {
java.sql.Driver mySqlDriver = DriverManager.getDriver("jdbc:mysql://localhost:3306/");
DriverManager.deregisterDriver(mySqlDriver);
} catch (SQLException ex) {
logger.info("Could not deregister driver:".concat(ex.getMessage()));
}
// 3. For added safety, remove the reference to dataSource for GC to enjoy.
dataSource = null;
}
}
Please feel free to comment and/or add...
This is purely driver registration/deregistration issue in mysql`s driver or tomcats webapp-classloader. Copy mysql driver into tomcats lib folder (so its loaded by jvm directly, not by tomcat), and message will be gone. That makes mysql jdbc driver to be unloaded only at JVM shutdown, and noone cares about memory leaks then.
If you are getting this message from a Maven built war change the scope of the JDBC driver to provided, and put a copy of it in the lib directory. Like this:
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.18</version>
<!-- put a copy in /usr/share/tomcat7/lib -->
<scope>provided</scope>
</dependency>
Solution for per-app deployments
This is a listener I wrote to solve the problem: it autodetects if the driver has registered itself and acts accordingly.it
Important: it is meant to be used ONLY when the driver jar is deployed in WEB-INF/lib, not in the Tomcat /lib, as many suggest, so that each application can take care of its own driver and run on a untouched Tomcat. That is the way it should be IMHO.
Just configure the listener in your web.xml before any other and enjoy.
add near the top of web.xml:
<listener>
<listener-class>utils.db.OjdbcDriverRegistrationListener</listener-class>
</listener>
save as utils/db/OjdbcDriverRegistrationListener.java:
package utils.db;
import java.sql.Driver;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.Enumeration;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import oracle.jdbc.OracleDriver;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
/**
* Registers and unregisters the Oracle JDBC driver.
*
* Use only when the ojdbc jar is deployed inside the webapp (not as an
* appserver lib)
*/
public class OjdbcDriverRegistrationListener implements ServletContextListener {
private static final Logger LOG = LoggerFactory
.getLogger(OjdbcDriverRegistrationListener.class);
private Driver driver = null;
/**
* Registers the Oracle JDBC driver
*/
#Override
public void contextInitialized(ServletContextEvent servletContextEvent) {
this.driver = new OracleDriver(); // load and instantiate the class
boolean skipRegistration = false;
Enumeration<Driver> drivers = DriverManager.getDrivers();
while (drivers.hasMoreElements()) {
Driver driver = drivers.nextElement();
if (driver instanceof OracleDriver) {
OracleDriver alreadyRegistered = (OracleDriver) driver;
if (alreadyRegistered.getClass() == this.driver.getClass()) {
// same class in the VM already registered itself
skipRegistration = true;
this.driver = alreadyRegistered;
break;
}
}
}
try {
if (!skipRegistration) {
DriverManager.registerDriver(driver);
} else {
LOG.debug("driver was registered automatically");
}
LOG.info(String.format("registered jdbc driver: %s v%d.%d", driver,
driver.getMajorVersion(), driver.getMinorVersion()));
} catch (SQLException e) {
LOG.error(
"Error registering oracle driver: " +
"database connectivity might be unavailable!",
e);
throw new RuntimeException(e);
}
}
/**
* Deregisters JDBC driver
*
* Prevents Tomcat 7 from complaining about memory leaks.
*/
#Override
public void contextDestroyed(ServletContextEvent servletContextEvent) {
if (this.driver != null) {
try {
DriverManager.deregisterDriver(driver);
LOG.info(String.format("deregistering jdbc driver: %s", driver));
} catch (SQLException e) {
LOG.warn(
String.format("Error deregistering driver %s", driver),
e);
}
this.driver = null;
} else {
LOG.warn("No driver to deregister");
}
}
}
I will add to this something I found on the Spring forums. If you move your JDBC driver jar to the tomcat lib folder, instead of deploying it with your webapp, the warning seems to disappear. I can confirm that this worked for me
http://forum.springsource.org/showthread.php?87335-Failure-to-unregister-the-MySQL-JDBC-Driver&p=334883#post334883
I found that implementing a simple destroy() method to de-register any JDBC drivers works nicely.
/**
* Destroys the servlet cleanly by unloading JDBC drivers.
*
* #see javax.servlet.GenericServlet#destroy()
*/
public void destroy() {
String prefix = getClass().getSimpleName() +" destroy() ";
ServletContext ctx = getServletContext();
try {
Enumeration<Driver> drivers = DriverManager.getDrivers();
while(drivers.hasMoreElements()) {
DriverManager.deregisterDriver(drivers.nextElement());
}
} catch(Exception e) {
ctx.log(prefix + "Exception caught while deregistering JDBC drivers", e);
}
ctx.log(prefix + "complete");
}
To prevent this memory leak, simply deregister the driver on context shutdown.
pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mywebsite</groupId>
<artifactId>emusicstore</artifactId>
<version>1.0-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<source>1.9</source>
<target>1.9</target>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<!-- ... -->
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.0.1.Final</version>
</dependency>
<dependency>
<groupId>org.hibernate.javax.persistence</groupId>
<artifactId>hibernate-jpa-2.0-api</artifactId>
<version>1.0.1.Final</version>
</dependency>
<!-- https://mvnrepository.com/artifact/mysql/mysql-connector-java -->
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.11</version>
</dependency>
<!-- https://mvnrepository.com/artifact/javax.servlet/servlet-api -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
</dependencies>
</project>
MyWebAppContextListener.java
package com.emusicstore.utils;
import com.mysql.cj.jdbc.AbandonedConnectionCleanupThread;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import java.sql.Driver;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.Enumeration;
public class MyWebAppContextListener implements ServletContextListener {
#Override
public void contextInitialized(ServletContextEvent servletContextEvent) {
System.out.println("************** Starting up! **************");
}
#Override
public void contextDestroyed(ServletContextEvent servletContextEvent) {
System.out.println("************** Shutting down! **************");
System.out.println("Destroying Context...");
System.out.println("Calling MySQL AbandonedConnectionCleanupThread checkedShutdown");
AbandonedConnectionCleanupThread.checkedShutdown();
ClassLoader cl = Thread.currentThread().getContextClassLoader();
Enumeration<Driver> drivers = DriverManager.getDrivers();
while (drivers.hasMoreElements()) {
Driver driver = drivers.nextElement();
if (driver.getClass().getClassLoader() == cl) {
try {
System.out.println("Deregistering JDBC driver {}");
DriverManager.deregisterDriver(driver);
} catch (SQLException ex) {
System.out.println("Error deregistering JDBC driver {}");
ex.printStackTrace();
}
} else {
System.out.println("Not deregistering JDBC driver {} as it does not belong to this webapp's ClassLoader");
}
}
}
}
web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
version="4.0">
<listener>
<listener-class>com.emusicstore.utils.MyWebAppContextListener</listener-class>
</listener>
<!-- ... -->
</web-app>
Source that inspired me for this bug fix.
I was having a similar problem, but additionally I was getting a Java Heap Space error anytime I modified/saved JSP pages with Tomcat server running, therefore the context were not fully recharged.
My versions were Apache Tomcat 6.0.29 and JDK 6u12.
Upgrading JDK to 6u21 as suggested in References section of URL http://wiki.apache.org/tomcat/MemoryLeakProtection solved the Java Heap Space problem (context now reloads OK) although JDBC Driver error still appears.
I found the same issue with Tomcat version 6.026.
I used the Mysql JDBC.jar in WebAPP Library as well as in TOMCAT Lib.
To fix the above by removing the Jar from the TOMCAT lib folder.
So what I understand is that TOMCAT is handling the JDBC memory leak properly. But if the MYSQL Jdbc jar is duplicated in WebApp and Tomcat Lib, Tomcat will only be able to handle the jar present in the Tomcat Lib folder.
I have faced this problem when I was deploying my Grails application on AWS. This is matter of JDBC default driver org.h2 driver .
As you can see this in the Datasource.groovy inside your configuration folder . As you can see below :
dataSource {
pooled = true
jmxExport = true
driverClassName = "org.h2.Driver" // make this one comment
username = "sa"
password = ""
}
Comment those lines wherever there is mentioned org.h2.Driver in the datasource.groovy file , if you are not using that database .
Otherwise you have to download that database jar file .
Thanks .
This error happened to me in a Grails Application with the JTDS Driver 1.3.0 (SQL Server). The problem was an incorrect login in SQL Server. After solve this issue (in SQL Server) my app was correctly deployed in Tomcat. Tip: I saw the error in stacktrace.log
In a simple app that I run on Open Liberty 21.0.0.8, I have provided an implementation of HttpAuthenticationMechanism:
// imports omitted
#CustomFormAuthenticationMechanismDefinition(
loginToContinue = #LoginToContinue(
loginPage = "/login.xhtml",
errorPage = "",
useForwardToLogin = false))
#ApplicationScoped
public class CustomAuthenticationMechanism implements HttpAuthenticationMechanism {
#Inject
private IdentityStoreHandler identityStoreHandler;
#Override
public AuthenticationStatus validateRequest(HttpServletRequest request,
HttpServletResponse response,
HttpMessageContext context) throws AuthenticationException {
Credential credential = context.getAuthParameters().getCredential();
if (credential != null) {
return context.notifyContainerAboutLogin(identityStoreHandler.validate(credential));
}
else {
return context.doNothing();
}
}
}
I expected Open Liberty to place that implementation of HttpAuthenticationMechanism into service.
However, on startup of Open Liberty a javax.enterprise.inject.spi.DeploymentException is thrown:
[INFO] [ERROR ] CWWKS1925E: The deployment for the dsgvo-management.war module in the dsgvo-management application failed because of multiple HttpAuthenticationMechanism implementations: de.knusperfisch.dsgvo.app.security.control.CustomAuthenticationMechanism, com.ibm.ws.security.javaeesec.cdi.beans.CustomFormAuthenticationMechanism. This failure is likely an application packaging issue. Make sure that each module has only one HttpAuthenticationMechanism implementation.
[INFO] [ERROR ] CWWKZ0004E: An exception occurred while starting the application dsgvo-management. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
[INFO] Exception 0 :
[INFO] javax.enterprise.inject.spi.DeploymentException: CWWKS1925E: The deployment for the dsgvo-management.war module in the dsgvo-management application failed because of multiple HttpAuthenticationMechanism implementations: de.knusperfisch.dsgvo.app.security.control.CustomAuthenticationMechanism, com.ibm.ws.security.javaeesec.cdi.beans.CustomFormAuthenticationMechanism. This failure is likely an application packaging issue. Make sure that each module has only one HttpAuthenticationMechanism implementation.
[INFO] at com.ibm.ws.security.javaeesec.cdi.extensions.JavaEESecCDIExtension.verifyConfiguration(JavaEESecCDIExtension.java:893)
[INFO] at com.ibm.ws.security.javaeesec.cdi.extensions.JavaEESecCDIExtension.afterBeanDiscovery(JavaEESecCDIExtension.java:173)
The Java EE Security API states that:
An application MAY supply its own HttpAuthenticationMechanism, if desired.
and:
An HttpAuthenticationMechanism must be a CDI bean, and is therefore
visible to the container through CDI if it is packaged in a bean
archive, which generally include Java EE modules and application
archives [...]
It MUST be possible for the definition of an
HttpAuthenticationMechanism to exist within the application archive
[...]
Is there a way in Open Liberty to configure a specific HttpAuthenticationMechanism for an app from an application archive, and if so, how is this done?
At first glance, as the error message indicates, looks like there are multiple HttpAuthMechanisms active which is not allowed. Are there are any apps that are using the #CustomFormAuthenticationMechanismDefinition annotation which would bring in the default com.ibm.ws.security.javaeesec.cdi.beans.CustomFormAuthenticationMechanism AuthMech in addition to your CustomAuthenticationMechanism ?
Kindly forgive the poor presentation and unethical coding lines if any
I'm trying to create my first jdbc class using embedded derby driver, I have created a maven project and added the following dependency
<dependency>
<groupId>org.apache.derby</groupId>
<artifactId>derby</artifactId>
<version>10.11.1.1</version>
</dependency>
I created a derby database in eclipse database developer, the ping to the database was successful, created a table and inserted values into it.
When I run the below java program
import java.sql.*;
import org.apache.derby.jdbc.*;
public class SiteDao implements SiteDaoInterface {
public static void main(String[] args)
{
String url ="jdbc:derby:C://Users//shash//MyDB;create=true";
String username="xyz";
String password="xyz";
String query="select * from practise.abc";
//Class.forName("org.apache.derby.jdbc.ClientDriver")
try {
//Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
//DriverManager.registerDriver(new org.apache.derby.jdbc.EmbeddedDriver());
Connection con=DriverManager.getConnection(url,username,password);
Statement st= con.createStatement();
ResultSet rs=st.executeQuery(query);
int i,j;
while( rs.next())
{
i=rs.getInt(1);
j=rs.getInt(2);
System.out.println("data is"+i+","+j);
}
st.close();
con.close();
} catch (SQLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
I'm encountering the below error.
Exception in thread "main" java.lang.NoSuchMethodError: 'void org.apache.derby.iapi.services.i18n.MessageService.setFinder(org.apache.derby.iapi.services.i18n.BundleFinder)'
at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unknown Source)
at org.apache.derby.impl.services.monitor.FileMonitor.<init>(Unknown Source)
at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown Source)
at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source)
at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source)
at org.apache.derby.jdbc.EmbeddedDriver.<clinit>(Unknown Source)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:377)
at com.smedia.dao.SiteDao.main(SiteDao.java:17)
I tried to go through the class mentioned in the error but encountered the below issue
I tried many solutions offered on internet but it didn't work
I'm using java 15.0.1 and even tried using derby-10.15.2.0 as suggested in some stackoverflow solutions but it didn't work (moreover there is no EmbeddedDriver class in 10.15.x.x version to my surprise)
Please let me know where am I ruining the code?
I am trying to insert an array to postgres using java code , but I always get this error :
SEVERE [http-nio-8080-exec-2]org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service()
for servlet [] in context with path [/] threw exception
[Servlet execution threw an exception] with root cause
java.lang.AbstractMethodError:
com.mchange.v2.c3p0.impl.NewProxyConnection.createArrayOf(Ljava/lang/String;[Ljava/lang/Object;)Ljava/sql/Array;
Code Used
pst = getConnection().prepareStatement(INSERT_QUERY,PreparedStatement.RETURN_GENERATED_KEYS);
pst.setString(1, t.getname());
pst.setString(2, t.getEmail());
Array itemIds = conn.createArrayOf("bigint", t.getItemIds());
pst.setArray(3, itemIds);
If I run the function through main class it works fine , but after deploying to tomcat server, http calls fail with above error .
DB Used - Postgres
JDBC Driver postgres-9.1-901-1.jdbc4
c3p0-0.9.5-pre10
tomcat-8.0.24
As per research I have done , createArrayOf() supposed to work with jdbc4 and c3p0-0.9.5 .
Using this works fine , but I don't see it as right approach
if (conn instanceof C3P0ProxyConnection) {
C3P0ProxyConnection proxy = (C3P0ProxyConnection) conn;
try {
Method m = Connection.class.getMethod("createArrayOf", String.class, Object[].class);
Object[] args = { "bigint", t.getItemIds() };
itemIds = (Array) proxy.rawConnectionOperation(m, C3P0ProxyConnection.RAW_CONNECTION, args);
} catch (IllegalArgumentException e) {
throw new SQLException(e);
}
} else {
itemIds = conn.createArrayOf("bigint", t.getItemIds());
}
Need help .
Thanks
I strongly suspect that you have an older version of c3p0 somewhere in your application's effective CLASSPATH. I've downloaded and verified from c3p0-0.9.5-pre10.jar and c3p0-0.9.5.1.jar on Maven Central that com.mchange.v2.c3p0.impl.NewProxyConnection does in fact contain the createArrayOf method.
% javap -sysinfo -cp ./c3p0-0.9.5.1.jar com.mchange.v2.c3p0.impl.NewProxyConnection
Classfile jar:file:/Users/swaldman/tmp/c3p0jars/c3p0-0.9.5.1.jar!/com/mchange/v2/c3p0/impl/NewProxyConnection.class
Last modified Jun 16, 2015; size 27098 bytes
MD5 checksum c1ff36b87219ddc84c92fb6c1445a2d1
Compiled from "NewProxyConnection.java"
public final class com.mchange.v2.c3p0.impl.NewProxyConnection implements java.sql.Connection,com.mchange.v2.c3p0.C3P0ProxyConnection {
//...
public synchronized java.sql.Array createArrayOf(java.lang.String, java.lang.Object[]) throws java.sql.SQLException;
//...
}
Although this is not likely the cause of your problem, I recommend that you do upgrade to c3p0-0.9.5.1 rather than using the prerelease version.
To see what version of c3p0 your application is actually using, look at INFO in your log files for the banner printed when the c3p0 library is initialized. It should look something like this:
INFO: Initializing c3p0-0.9.5.1 [built 16-June-2015 00:06:36 -0700; debug? true; trace: 10]
I suspect that you will see an older version, that somewhere, perhaps among the transitive dependencies, you are pulling in 0.9.1.x or 0.9.2.x versions of the library.
Good luck!
I can see you are using old version of the c3p0 library.
if you are using maven, update the library to higher version in you pom file from
<dependency>
<groupId>c3p0</groupId>
<artifactId>c3p0</artifactId>
<version>0.9.1.2</version>
</dependency>
to
<dependency>
<groupId>com.mchange</groupId>
<artifactId>c3p0</artifactId>
<version>0.9.5.2</version>
</dependency>
I hope it help someone.
Updating dependency to following solved my problem.
<dependency>
<groupId>com.mchange</groupId>
<artifactId>c3p0</artifactId>
<version>0.9.5.2</version>
</dependency>
I get this error when I try to access to the servlet named BookingServlet
Grave: exception caught
javax.naming.NamingException: Lookup failed for 'java:global/it.volaconnoi_VolaConNoi_webapp-ear_ear_1.0-SNAPSHOT/it.volaconnoi_VolaConNoi_webapp-ejb_ejb_1.0-SNAPSHOT/BookingBean!it.volaconnoi.logic.BookingBeanInterface' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NameNotFoundException: it.volaconnoi_VolaConNoi_webapp-ear_ear_1.0-SNAPSHOT]
and this is the screenshot
The project is deployed correctly but I don't understand why I get this error. Do you any suggest?
As you may see the booking servlet is in its place
EDIT
BookingBeanInterface bookingBean = lookupBookingBeanLocal();
private BookingBeanInterface lookupBookingBeanLocal() {
try {
Context c = new InitialContext();
return (BookingBeanInterface) c.lookup("java:global/it.volaconnoi_volaconnoi-webapp-ear_ear_1.0-SNAPSHOT/it.volaconnoi_volaconnoi-webapp-ejb_ejb_1.0-SNAPSHOT/BookingBean!it.volaconnoi.logic.BookingBeanInterface");
} catch (NamingException ne) {
Logger.getLogger(getClass().getName()).log(Level.SEVERE, "exception caught", ne);
throw new RuntimeException(ne);
}
}
Really not enough description, you should describe where is your class BookingBean is located, and by what means it registered in JNDI. But if we assume that registration is correct, you could try to lookup it using following string:
c.lookup("java:app/BookingBean/it.volaconnoi.logic.BookingBeanInterface");
See more description here: http://docs.oracle.com/javaee/6/tutorial/doc/gipjf.html