Description of problem: Tomcat creates a classpath starting with ":". At least java-1.6.0-openjdk and java-1.7.0-openjdk interpret that as having "." in the classpath. Also, the tomcat service starts in the directory "/". Thus, any class from a package starting with "net." first checks in the automount directory, causing long delays due to DNS lookup of a non-existing host. Version-Release number of selected component (if applicable): tomcat-7.0.33-2.fc17.noarch How reproducible: Always Steps to Reproduce: 1. Configure automount "-hosts" for the /net directory. 2. Use a Java class net.* 3. Access it from Tomcat Actual results: A long delay whenever that class is accessed. Expected results: Do not include the current directory ("/") in the classpath. Additional info: The problem is in /usr/sbin/tomcat: # CLASSPATH munging if [ -n "$JSSE_HOME" ]; then CLASSPATH="${CLASSPATH}:$(build-classpath jcert jnet jsse 2>/dev/null)" fi CLASSPATH="${CLASSPATH}:${CATALINA_HOME}/bin/bootstrap.jar" The Apache distribution for Tomcat handles that better in the file catalina.sh: # Add on extra jar files to CLASSPATH if [ ! -z "$CLASSPATH" ] ; then CLASSPATH="$CLASSPATH": fi CLASSPATH="$CLASSPATH""$CATALINA_HOME"/bin/bootstrap.jar
A colleague suggested putting a CLASSPATH entry into /etc/tomcat/tomcat.conf as a workaround. That works as long as the file or directory exists. E.g., "/tmp" works but using "aa.jar" causes a FileNotFoundException.
While the classpath is the most serious problem, it would make more sense to use $CATALINA_HOME instead of "/" as the current working directory for the service. That would avoid the problem with "/net", too.
tomcat-7.0.34-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/tomcat-7.0.34-1.fc18
Package tomcat-7.0.34-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing tomcat-7.0.34-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20939/tomcat-7.0.34-1.fc18 then log in and leave karma (feedback).
If you can also provide a Fedora 17 version, I'll test it and leave karma.
Build of 7.0.34 for f17 http://koji.fedoraproject.org/koji/taskinfo?taskID=4817874 is blocked by not yet pushed to stable https://admin.fedoraproject.org/updates/FEDORA-2012-16497/ecj-4.2.1-1.fc17 You can test it and leave karma there.
(In reply to comment #6) > Build of 7.0.34 for f17 > http://koji.fedoraproject.org/koji/taskinfo?taskID=4817874 is blocked by not > yet pushed to stable > https://admin.fedoraproject.org/updates/FEDORA-2012-16497/ecj-4.2.1-1.fc17 > > You can test it and leave karma there. It looks like the build failed, maybe because ecj-4.2.1-1.fc17 is needed.
tomcat-7.0.34-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Why did this bug get closed? There isn't a version available for testing in Fedora 17. Fedora 18 will only be released next week.
ecj-4.2.1-2.fc17.x86_64 is in testing. It works for me with tomcat-7.0.33-2.fc17. Please build tomcat-7.0.34-1.fc17 using the test version of ecj.
tomcat-7.0.35-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/tomcat-7.0.35-1.fc17
tomcat-7.0.37-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/tomcat-7.0.37-1.fc17
tomcat-7.0.37-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/tomcat-7.0.37-1.fc18
tomcat-7.0.37-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.