[Bug 55368] New: Default Tomcat install is no longer auto-registering JDBC type 4 drivers

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=55368

            Bug ID: 55368
           Summary: Default Tomcat install is no longer auto-registering
                    JDBC type 4 drivers
           Product: Tomcat 6
           Version: 6.0.36
          Hardware: PC
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: mwick@loftware.com

Created attachment 30681
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=30681&action=edit
Reproduction Case

Type 4 JDBC drivers included in ${CATALINA_HOME}/lib, or the CLASSPATH in
general, should be auto-registered so that they can be loaded the first time
they are accessed.  This works up through Tomcat 6.0.33.  It does not work in
Tomcat 6.0.35; only the ODBC-JDBC bridge driver is auto-registered.  

It appears that this is a result of the work done to fix bug 51640.  If I
provide the attribute driverManagerProtection="false" to the
JreMemoryLeakPreventionListener, effectively disabling the fix for 51640, the
drivers auto-register as they did before.

I have attached a small JSP page and instructions that show this behavior.

This is being run under Java 1.7.0_25.  Tomcat is not being run behind a web
server.  We are running Coyote and the AJP connector.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 55368] Default Tomcat install is no longer auto-registering JDBC type 4 drivers

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=55368

Nick Williams <ni...@nicholaswilliams.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 OS|                            |All

--- Comment #1 from Nick Williams <ni...@nicholaswilliams.net> ---
I'll wait for someone more knowledgeable to chime in, but if I remember the
discussion correctly this is actually the intended behavior.

DriverManager is really just a big memory leak waiting to happen. If you load a
JDBC Driver from the wrong ClassLoader (for example, if you put a JDBC driver
in /WEB-INF/lib, which you really shouldn't do anyway), when it registers with
the DriverManager the Class and Driver instance leak into the System
ClassLoader. The Driver can then be accessed from any code in the JVM,
including other web applications. This is a design flaw in the DriverManager
(at least, many people feel that way) that will probably never be fixed.

IIRC, the fix for bug 51640 intentionally resulted in stopping DriverManager
from automatically discovering and loading Drivers because that was the best
way to fix the problem. But I could be mistaken.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 55368] Default Tomcat install is no longer auto-registering JDBC type 4 drivers

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=55368

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #2 from Mark Thomas <ma...@apache.org> ---
Nick is correct.

The default setting for driverManagerProtection triggers a call to
DriverManager.getDrivers() with the current class loader set to the system
class loader. This is to avoid memory leaks if the call to
DriverManager.getDrivers() is triggered by a web application.

I'd add that you can get all sorts of strange behaviour wihtout this option
enabled depending on what web applciations include which drivers and the order
that the web applications are started and/or accessed.

There is no way to have automatic registration and no memory leaks. The system
class loader (rather than Tomcat's class loader that includes
${CATALINA_HOME}/lib) is used to prevent memory leaks when Tomcat is used in an
embedded scenario.

You are, of course, free to disable this setting if you prefer to have
automatic registration along with the memory leak risks that go along with
that. For more info on the memory leaks see this presentation:
http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

[Bug 55368] Default Tomcat install is no longer auto-registering JDBC type 4 drivers

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=55368

--- Comment #3 from mwick@loftware.com ---
I appreciate your position, but please consider documenting or release noting
the functional change.  I wasn’t expecting that a memory leak check would cause
a change in the functional behavior of the product – as I’m sure most of your
users weren’t.  A cursory search of the web finds many instances of people
asking why they are suddenly seeing the “No suitable driver” error.  Granted,
most are using JDBC wrong, but a little documentation would go a long way.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org