Created attachment 342426 [details] tomcat-7 init.d script with hotfix (just a PoC) The tomcat-7 init script (generated from /usr/share/tomcat-7/gentoo/tomcat-instance-manager.bash) specify explicitely the classpath with the libraries in /usr/share/tomcat-7/lib (. This cause classloading problems for the tomcat-jdbc library (but could be a the problem for other components too). As specified for driverClassName property in http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html --------------------------------------------------- driverClassName: (String) The fully qualified Java class name of the JDBC driver to be used. The driver has to be accessible from the same classloader as tomcat-jdbc.jar --------------------------------------------------- And as stated in http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html it's tomcat itself that load the libraries in $catalina_base/lib etc... Providing these libraries while starting the java process, interfere with the tomcat classloading behaviors. In this specific problem using for example the new connection pool "org.apache.tomcat.jdbc.pool.DataSource" provided by the tomcat-jdbc.jar there'se no way to find the jdbc driver in all these common places: * WEB-INF/libs * $CATALINA_BASE/libs * $CATALINA_HOME/libs Launching tomcat removing all /usr/share/tomcat-7/lib packages from the classpath proved to solve the problem.
Other than solve this specific problem (and maybe someone with better bash skill could dynamically strip the libraries from the java-config output... or other solutions, i don't know..) I think that gentoo needs to move in a way to provide an environment as close as possible to the official apache packages. It's amazing the ability to use distro-tools for a package like tomcat in production environments, but too often I saw (and continue to see) people discarding the distro-packages and prefer the official package to avoid these sort of problems (and honestly I can't blame them). So giving the love for gentoo, I really would like to help in this way. This is a "snapshot" of the command launched from the "startup.sh" script in the latest apache official tomcat v 7.0.37 (newlines in classpath for help in reading) ----------------- /etc/java-config-2/current-system-vm/bin/java -Djava.util.logging.config.file=/srv/apache-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/srv/apache-tomcat/endorsed -classpath /srv/apache-tomcat/bin/bootstrap.jar /srv/apache-tomcat/bin/tomcat-juli.jar -Dcatalina.base=/srv/apache-tomcat -Dcatalina.home=/srv/apache-tomcat -Djava.io.tmpdir=/srv/apache-tomcat/temp org.apache.catalina.startup.Bootstrap start ------------------ These is instead the init.d/tomcat-7 resulting command (without the hotfix) /opt/sun-jdk-1.6.0.43/bin/java -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/var/lib/tomcat-7/conf/logging.properties -Dcatalina.base=/var/lib/tomcat-7 -Dcatalina.home=/usr/share/tomcat-7 -Djava.io.tmpdir=/var/tmp/tomcat-7 -classpath /usr/share/tomcat-7/bin/bootstrap.jar /usr/share/tomcat-7/bin/tomcat-juli.jar /usr/share/tomcat-7/lib/annotations-api.jar /usr/share/tomcat-7/lib/catalina-ant.jar /usr/share/tomcat-7/lib/catalina-ha.jar /usr/share/tomcat-7/lib/catalina-tribes.jar /usr/share/tomcat-7/lib/catalina.jar /usr/share/tomcat-7/lib/jasper-el.jar /usr/share/tomcat-7/lib/jasper.jar /usr/share/tomcat-7/lib/tomcat-api.jar /usr/share/tomcat-7/lib/tomcat-coyote.jar /usr/share/tomcat-7/lib/tomcat-i18n-es.jar /usr/share/tomcat-7/lib/tomcat-i18n-fr.jar /usr/share/tomcat-7/lib/tomcat-i18n-ja.jar /usr/share/tomcat-7/lib/tomcat-util.jar /usr/share/tomcat-7/lib/tomcat-jdbc.jar /usr/share/eclipse-ecj-3.7/lib/ecj.jar /usr/share/tomcat-servlet-api-3.0/lib/el-api.jar /usr/share/tomcat-servlet-api-3.0/lib/jsp-api.jar /usr/share/tomcat-servlet-api-3.0/lib/servlet-api.jar org.apache.catalina.startup.Bootstrap jpda start
I see now, it's the same problem of #453212
*** This bug has been marked as a duplicate of bug 453212 ***
