DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25029>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25029 Memory leak registering JDBC drivers. ------- Additional Comments From [EMAIL PROTECTED] 2003-11-28 07:31 ------- Not quite sure this is really a bug but I am open to suggestions. Here are some thoughts... 1) The DefaultConnectionPool was never really meant for production use, it was included so that command line execution was supported using the same mechanism’s as an external connection pool. Using the DefaultConnectionPool and supplying the connection info in the Stylesheet, IMHO, seems like a maintenance issue and could be a minor security risk 2) The XConnection has support for Container based Connection Pools, JDBC 2 / JNDI connections and any other Connection pool mechanism. All that is needed is a wrapper class that supports the translation from interface ConnectionPool and the target connection pool. You would have to create a class outside the Xalan process then register it with the ConnectionPoolManager. See the ExternalConn example code for an example. 3) The instantiaon of the Driver outside of the DriverManager was to support some odd JDBC drivers that would auto unregister when the connection count was 0. There were also some other problems with JDK 1.4 and ContextClassLoading when using the DefaultConnectionPool in Tomcat 4.x 4) Xalan was, not sure if it still is, restricted to JDK 1.1.8 so none of the JDBC 2 features could be used.
