tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Petermann <matth...@petermann-it.de>
Subject Re: ClassNotFoundException org.apache.juli.FileHandler in Tomcat 7.0.42 / OpenJDK 6 b27 (FreeBSD)
Date Sat, 13 Jul 2013 18:04:15 GMT
Am 13.07.2013 16:07, schrieb Konstantin Kolinko:
> 2013/7/13 Konstantin Kolinko <knst.kolinko@gmail.com>:
>> 2013/7/13 Matthias Petermann <matthias@petermann-it.de>:
>>> Hello,
>>>
>>> when I try to start Tomcat 7.0.42 with OpenJDK 6 b27, it complains about not
>>> finding classes for the logging handlers. I created a minimal
>>> logging.properties to narrow down the problem:
>>>
>>>      handlers = 1catalina.org.apache.juli.FileHandler,
>>> java.util.logging.ConsoleHandler
>>>      .handlers = java.util.logging.ConsoleHandler
>>>
>>>      1catalina.org.apache.juli.FileHandler.level = FINE
>>>      1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
>>>      1catalina.org.apache.juli.FileHandler.prefix = catalinatest.
>>>
>>>      java.util.logging.ConsoleHandler.level = FINE
>>>      java.util.logging.ConsoleHandler.formatter =
>>> java.util.logging.SimpleFormatter
>>>
>>> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
>>> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers =
>>> 1catalina.org.apache.juli.FileHandler
>>>
>>> The output of "./catalina.sh run" is the following:
>>>
>>>      INFO: Starting Servlet Engine: Apache Tomcat/7.0.42
>>>      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:217)
>>>          at java.security.AccessController.doPrivileged(Native Method)
>>>          at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
>>>          at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
>>>          at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
>>>          at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
>>>          at java.util.logging.LogManager$3.run(LogManager.java:654)
>>>          at java.security.AccessController.doPrivileged(Native Method)
>>>          at
>>> java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:641)
>>>          at java.util.logging.LogManager.access$900(LogManager.java:150)
>>>          at
>>> java.util.logging.LogManager$LoggerContext.addLogger(LogManager.java:437)
>>>          at
>>> java.util.logging.LogManager$UserLoggerContext.demandLogger(LogManager.java:596)
>>>          at
>>> java.util.logging.LogManager$LoggerContext.demandLogger(LogManager.java:475)
>>>          at java.util.logging.Logger.getLogger(Logger.java:329)
>>>          at org.apache.juli.logging.DirectJDKLog.<init>(DirectJDKLog.java:71)
>>>          at
>>> org.apache.juli.logging.DirectJDKLog.getInstance(DirectJDKLog.java:196)
>>>          at
>>> org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:170)
>>>          at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:311)
>>>          at
>>> org.apache.catalina.core.ContainerBase.getLogger(ContainerBase.java:452)
>>>          at
>>> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1102)
>>>          at
>>> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:800)
>>>          at
>>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>>>          at
>>> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
>>>          at
>>> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
>>>          at
>>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>>>          at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>>>          at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
>>>          at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>          at java.lang.Thread.run(Thread.java:679)
>>>
>>> There can be found many mentions on this topic on the web, each of them
>>> proposing one of those solutions which I tried:
>>>
>>>   * Check/set JAVA_HOME / JRE_HOME
>>>
>>>          $ export JAVA_HOME=/usr/local/openjdk6/
>>>          $ export JRE_HOME=/usr/local/openjdk6/jre/
>>>
>>>   * Check/set CATALINA_HOME
>>>
>>>          $ export
>>> CATALINA_HOME=/home/mpeterma/System/Apps/apache-tomcat-7.0.42
>>>
>>>   * Ensure LOGGING_CONFIG and LOGGING_MANAGER are set properly
>>>
>>>          --> validated, LOGGING_MANAGER is set to
>>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager in
>>> catalina.sh if unspecified, which should be correct; LOGGING_CONFIG is found
>>> because it contains the handlers where Tomcat complains about
>>>
>>>   * Ensure tomcat-juli.jar is in the classpath
>>>
>>>          --> validated, it's using
>>> /home/mpeterma/System/Apps/apache-tomcat-7.0.42/bin/bootstrap.jar:/home/mpeterma/System/Apps/apache-tomcat-7.0.42/bin/tomcat-juli.jar
>>>
>>>   * Place tomcat-juli.jar into Tomcat lib folder  --> tested, unsuccessful
>>>   * Place tomcat-juli.jar into OpenJDK / JRE lib folder(s) --> tested,
>>>     unsuccessful
>>>
>>> None of this proposals fixed the problem for me. When I comment out the
>>> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].* -lines from
>>> logging.properties, the problem disappears. Anyway - this is not a solution
>>> as the logging is not working then.
>>>
>>> The only workaround which *is* working is to use OpenJDK 7 instead of
>>> OpenJDK 6. But I would like to make it run on OpenJDK 6.
>>>
>>>      $ java -version
>>>      openjdk version "1.6.0_32"
>>>      OpenJDK Runtime Environment (build 1.6.0_32-b27)
>>>      OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
>>>
>>> Is there a known problem with this JDK or with OpenJDK in general? It might
>>> be noteworty that I have this problem on FreeBSD only. The Linux version of
>>> OpenJDK 6 b27 (reports as IcedTea6 / OpenJDK 6 b27) works.
>>>
>>> There was a bug report filed against the FreeBSD OpenJDK 6 port already:
>>>
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=177067&cat=
>>>
>>> At this time it is not clear to me where to look for the root cause. I
>>> appreciate your help and hints, looking for directions where to investigate
>>> in detail.
>>>
>>
>> This is the first time I see such issue being reported for OpenJDK6,
>> but there certainly have been the same issue with openjdk 1.7.0.9 four
>> months ago.
>>
>> See this thread,
>> "tomcat 7.0.37 and openjdk 1.7.0.9 on fedora juli FileHandler problems"
>> from March 2013:
>> http://tomcat.markmail.org/thread/pgmc7nh3vv5jqt7w
>>
> To repeat from that thread, essentially the
> "-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager"
> setting is being ignored and default java.util.logging.LogManager is
> used instead.  Hilarity ensues.
>
> Googling further regarding the issue in 1.7.0.9 I cannot get anything
> useful from openjdk.java.net (the openjdk sites are not responding as
> of now), but I found this:
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=908497
>
> So the issue was present in
> java-1.7.0-openjdk-1.7.0.9-2.3.5.fc18
> and fixed in
> java-1.7.0-openjdk-1.7.0.9-2.3.5.fc18.1
>
> Looking at spec file in srcrpm for the latter, there is the following patch:
> [[[
> # Back out 6664509 which bnreaks custom log managers
> Patch1000: sec-2013-02-01-6664509.patch
> ]]]
>
> and finally
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=907344
> See comments 5 and 10 there.
>
> Apparently this bug was caused by an attempt to fix a security issue
> (CVE-2013-0425).
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Hi Konstantin,

many thanks for your inquiries! Everything becomes a bit clearer now.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=907344 (Comment 10)

The posting confirms the issue was caused by the IcedTea6 patches and 
not the OpenJDK itself. And as it was fixed in 1.11.6, my Linux box 
(IcedTea 1.12.5) doesn't show up the problems with the Juli logger I 
have seen on my FreeBSD box.

Looks like the IcedTea6 patch set in FreeBSD ports is older than 1.11.6. 
I will try to find out more and contact the maintainer.

So far - I am happy now to be a bit closer to the root cause.

Thanks again & kind regards,
Matthias



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


Mime
View raw message