Bug #6850 | connector/j 3.1.4 does not work in particular configuration while 3.0.16 works | ||
---|---|---|---|
Submitted: | 26 Nov 2004 15:22 | Modified: | 1 Dec 2004 23:21 |
Reporter: | Alessandro Polverini | Email Updates: | |
Status: | Can't repeat | Impact on me: | |
Category: | Connector / J | Severity: | S2 (Serious) |
Version: | 3.1.4 beta | OS: | Linux (Debian Sarge GNU/Linux) |
Assigned to: | Eric Herman | CPU Architecture: | Any |
[26 Nov 2004 15:22]
Alessandro Polverini
[29 Nov 2004 20:39]
Eric Herman
My suspicion is that this is a class loading issue and version conflict. It doesn't look like c3p0 ships with a Connector/J driver, but my best guess is that there is one somewhere in the web-app which uses c3p0. I have not yet put together a "sample app" using c3p0 ... but that seems to be the next step, if we can't find the conflict. There are some examples in the c3p0 package that look useful, however, so that shouldn't be too hard. But first, can we establish for certain that the other web app doesn't also have a version of the Connector/J in its classpath? Perhaps in web-inf? Maybe jre/lib/ext or something? Let's take a close look at what else is in the common/endorsed folder(s). And shared/lib. -- Eric Herman
[29 Nov 2004 21:06]
Alessandro Polverini
Hello Eric, and thanks for your reply. I double checked every jar: the ones common to tomcat, and those of the webapps. No other versions of the connector are present. Here are the jars in my system (not including the connector). in /usr/share/tomcat5/common/endorsed/ xalan.jar xercesImpl.jar xml-apis.jar in /usr/share/tomcat5/shared/lib/: c3p0-0.8.5-pre2.jar cglib-full-2.0.1.jar jstl.jar standard.jar taglibs-datetime.jar and in my WEB-INF/lib: batik-1.5.jar dom4j-1.4.jar jcommon-0.9.1.jar cewolf.jar ehcache-0.7.jar freechart-0.9.8.jar commons-logging-1.0.3.jar hibernate2.jar log4j-1.2.8.jar odmg-3.0.jar Hope this helps, Alex
[1 Dec 2004 23:21]
Mark Matthews
I've put together a system similar to what you have (i.e. Tomcat, driver .jar in common/endorsed, c3p0 in WEB-INF/lib), and given the following simple .jsp, can't repeat this (i.e. this works on my end). Unless you can give us more information on how to repeat this bug, or can do us a favor and attach a debugger to your setup so you might see where your app is trying to load classes from, I'm afraid we'll have to put this into the 'cant repeat' column :( ---8<------- JSP Test ---- 8<--------- <jsp:directive.page import="java.sql.*"/> <jsp:directive.page import="javax.sql.DataSource"/> <jsp:directive.page import="com.mchange.v2.c3p0.DataSources"/>; <% /** * This example shows how to programmatically get and directly use * an pool-backed DataSource */ try { // Note: your JDBC driver must be loaded [via Class.forName( ... ) or -Djdbc.properties] // prior to acquiring your DataSource! Class.forName("com.mysql.jdbc.Driver"); // Acquire the DataSource... this is the only c3p0 specific code here DataSource unpooled = DataSources.unpooledDataSource("jdbc:mysql://localhost/test", "root", ""); DataSource pooled = DataSources.pooledDataSource( unpooled ); // get hold of a Connection an do stuff, in the usual way Connection con = null; Statement stmt = null; ResultSet rs = null; try { con = pooled.getConnection(); stmt = con.createStatement(); rs = stmt.executeQuery("SELECT 'abc'"); while (rs.next()) {%> <%=rs.getString(1) %> <% } } finally { //i try to be neurotic about ResourceManagement, //explicitly closing each resource //but if you are in the habit of only closing //parent resources (e.g. the Connection) and //letting them close their children, all //c3p0 DataSources will properly deal. //attemptClose(rs); //attemptClose(stmt); //attemptClose(con); } } catch (Exception e) { e.printStackTrace(); } %>
[6 Dec 2004 15:29]
Alessandro Polverini
Your example works fine with me too. Maybe the problem is that c3p0 is used inside a servlet and not in a JSP page like the example you provide? Anyway, thanks for your time, I'll try to reproduce the problem in a more restricted environment. Not I must solve another problem: with the 3.1.4 driver I've an incorrect handling of characters like "é". "ì" etc (i.e.: characters with accents, outside the iso-8859-1 charset). But I think I'll have to open another bug for that. Alex
[6 Dec 2004 16:06]
Mark Matthews
Technically, a JSP _is_ a servlet (the JSP engine generates a Class that extends HTTPServlet in all appservers that I've had experience with), so it uses the same classloaders and other machinery that a servlet would.
[6 Dec 2004 17:02]
Alessandro Polverini
Yes I know that a JSP is traslated in a servlet but maybe in this particular situation the problem is that the servlet has the load-on-startup flag set and maybe in this case there are problems in the order classes are loaded. This is only a wild guess anyway :(
[21 Dec 2007 3:23]
Ondra Zizka
I have a similar problem with current versions of J/Connector and SJSAS. Should I look for conflicting version of connector somewhere inside the SJSAS and app's classpath? The app does not work no matter where I put the connector .jar, except for the server's lib/endorsed directory.