thanks for the responses, it gave me a different thing to search for and found the answer .... openjdk1.7.0.9 is broken. I didn't find the original bug report but I found others talking about it.
https://community.jboss.org/message/796354?_sscc=t Indeed when I downgrade to openjdk1.7.0.3 it all works as expected. Cheers. Ted. On 3/6/13, Mark Eggers <its_toas...@yahoo.com> wrote: > On 3/5/2013 5:32 PM, Konstantin Kolinko wrote: >> 2013/3/6 Ted <r6squee...@gmail.com>: >>> Hi I'm running fedora 16, openjdk 1.7.0.9 and tomcat 7.0.37 (from a >>> tar.gz). >>> >>> I'm getting a juli FileHandler problem and the existing posts / google >>> search results do not appear to be the same as mine. I'm running >>> tomcat freshly un-tarred from the tar.gz with catalina.sh run (not my >>> webap or anything else, no changes to catalina.sh or >>> logging.properties or any of the tomcat contents), so the juli jar is >>> in bin and the -D logging option is what ever is in catalina.sh. >>> >>> I'm getting the stack trace : >>> >>> [1027:/data/apps/apache-tomcat-7.0.37]catalina.sh run >>> Using CATALINA_BASE: /data/apps/apache-tomcat-7.0.37 >>> Using CATALINA_HOME: /data/apps/apache-tomcat-7.0.37 >>> Using CATALINA_TMPDIR: /data/apps/apache-tomcat-7.0.37/temp >>> Using JRE_HOME: /data/apps/openjdk1.7.0.9 >>> Using CLASSPATH: >>> /data/apps/apache-tomcat-7.0.37/bin/bootstrap.jar:/data/apps/apache-tomcat-7.0.37/bin/tomcat-juli.jar >>> Can't load log handler "1catalina.org.apache.juli.FileHandler" >>> java.lang.ClassNotFoundException: >>> 1catalina.org.apache.juli.FileHandler >>> java.lang.ClassNotFoundException: >>> 1catalina.org.apache.juli.FileHandler >>> at >>> java.net.URLClassLoader$1.run(URLClassLoader.java:366) >>> at >>> java.net.URLClassLoader$1.run(URLClassLoader.java:355) >>> at java.security.AccessController.doPrivileged(Native >>> Method) >>> at >>> java.net.URLClassLoader.findClass(URLClassLoader.java:354) >>> at >>> java.lang.ClassLoader.loadClass(ClassLoader.java:423) >>> at >>> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) >>> >> >> Any more lines in the stack trace? >> It certainly looks like a work of default JRE's >> java.util.logging.LogManager implementation. >> >> That is as if >> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager >> setting was not effective. >> It reads the correct file though, so the file name was passed >> successfully. >> >> You may try to simplify the logging.properties file so that it >> conforms to the format expected by the default LogManager. That is, >> remove all loggers with numerical prefixes and leave only >> ConsoleLogger there. >> >> That way you can get working logging and try to start Tomcat and see >> whether it fails further along the way (e.g. whether it can load other >> classes from tomcat-juli.jar). >> >>> >>> I should note that the above works when I use oracle-jdk1.7.0_17. I'm >>> suspecting this is a problem with openjdk but more like a "configure >>> openjdk to work with tomcat" issue. >>> >>> Does anyone know what configuration changes need to be made to openjdk >>> to work with tomcat's juli logger? >>> >> >> Best regards, >> Konstantin Kolinko > > I just started up a stock Tomcat 7.0.33 with the following environment. > > OS: Fedora 18 3.8.1-201.fc16.x86_64 > JVM: 1.7.0_09-icedtea-mockbuild_2013_02_20_08_13-b00 > > I have the following RPM installed: > > java-1.7.0-openjdk-1.7.0.9-2.3.7.0.fc18.x86_64 > > This, surprisingly enough, is the JRE. The JDK is (I think): > > java-1.7.0-openjdk-devel-1.7.0.9-2.3.7.0.fc18.x86_64 > > I had to tweak my settings a bit since I normally run Oracle's JRE. > Basically I removed JRE_HOME, JDK_HOME from my environment, removed > Oracle's JRE and JDK from my path, and then used startup.sh to run Tomcat. > > I don't use the alternatives mechanism. I create links and set up paths > in custom.sh (you'll do that in /etc/profile.sh). > > Note BTW that Fedora 16 has reached EOL. No further updates or packages > are available. > > How did you install Java? It appears that the openjdk RPM scatters > things all over. I found that not setting JRE_HOME or JAVA_HOME worked > fine for me. > > . . . . just my two cents. > /mde/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org