tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 34080] New: - JDBCRealm looses original exception, fabricates exception type
Date Sat, 19 Mar 2005 04:28:32 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34080>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34080

           Summary: JDBCRealm looses original exception, fabricates
                    exception type
           Product: Tomcat 5
           Version: Nightly Build
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: daniel.santos@pobox.com


naughty, naughty programmer ditches the original exception.  See line 684 of
current nightly build of org.apache.catalina.realm.JDBCRealm.java

        // Instantiate our database driver if necessary
        if (driver == null) {
            try {
                Class clazz = Class.forName(driverName);
                driver = (Driver) clazz.newInstance();
            } catch (Throwable e) {
                throw new SQLException(e.getMessage());
            }
        }

As you can see, only the message of the exception is retained which is usually
meaningless without knowning the exception it's self.  The original stack trace
is also lost.  To make matters worse, SQLException doesn't take a rootCause to
show you this because it expects this to come from a DBMS and not a driver class
loading routine.

The issues surrounding this "catch Throwable" is that Class.forName() can throw
some nasty errors and we dont want a bad JDBC realm configuration to bring down
Tomcat.  The possible Throwables from this try block are:

LinkageError
ExceptionInInitializerError
ClassNotFoundException
ClassCastException

Additionally, ExceptionInInitializerError can contain an exception from the
static initializer of the driver class that failed to load, compounding the
original lost exception issue.  This presents a diverse array of possible problems.

I propose we throw a LifeCycleException, but catch it in the start() method.  If
I understand the logic correctly, we want to let the app start up if they aren't
using authentication, even though they don't have their realm configured correctly.

Feedback please?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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


Mime
View raw message