[Java] Can't load log handler "1catalina.org.apache.juli.AsyncFileHandler"

When starting our tomcat 9 server with our agent in place, we are seeing the following exception:

Can’t load log handler “1catalina.org.apache.juli.AsyncFileHandler”
java.lang.ClassNotFoundException: 1catalina.org.apache.juli.AsyncFileHandler
java.lang.ClassNotFoundException: 1catalina.org.apache.juli.AsyncFileHandler
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.util.logging.LogManager$5.run(LogManager.java:965)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958)
at java.util.logging.LogManager.addLogger(LogManager.java:1165)
at java.util.logging.LogManager$2.run(LogManager.java:349)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.ensureLogManagerInitialized(LogManager.java:338)
at java.util.logging.LogManager.getLogManager(LogManager.java:378)
at java.util.logging.Logger.getPlatformLogger(Logger.java:572)
at java.util.logging.LoggingProxyImpl.getLogger(LoggingProxyImpl.java:41)
at sun.util.logging.LoggingSupport.getLogger(LoggingSupport.java:100)
at sun.util.logging.PlatformLogger$JavaLoggerProxy.(PlatformLogger.java:602)
at sun.util.logging.PlatformLogger$JavaLoggerProxy.(PlatformLogger.java:597)
at sun.util.logging.PlatformLogger.(PlatformLogger.java:239)
at sun.util.logging.PlatformLogger.getLogger(PlatformLogger.java:198)
at sun.util.locale.provider.LocaleServiceProviderPool.config(LocaleServiceProviderPool.java:142)
at sun.util.locale.provider.LocaleProviderAdapter.(LocaleProviderAdapter.java:165)
at java.text.DecimalFormatSymbols.getInstance(DecimalFormatSymbols.java:178)
at java.text.DecimalFormat.(DecimalFormat.java:435)

The configuration that we are using is identical to an existing tomcat instance and applications, the only change that could be causing this is the change in tomcat version.

We are running a portal application called liferay, this has been upgraded to 7.2, and the logging configuration that creates the handlers is part of this. although this, again is the same logging that was used in the previous version.

The agent version is 5.5.0

Hi Mark,

I would suggest using the latest version of the Java agent 5.10 -> https://docs.newrelic.com/docs/release-notes/agent-release-notes/java-release-notes/java-agent-5100 this has all the latest configurations for our logging tool.

In your stack trace I don’t see any relevance to the New relic agent / Jar. are you sure this is related to New Relic.

Have you been able to get the logging tool working without any of the New Relic instrumentation?

Hey Glen,

Thanks for the suggestion. I will try the latest agent and see if that helps. This error only occurs when we add in the agent to the startup args on apache, so I can only assume that it’s this causing the problem! I do believe that it is still logging metrics but it would make me nercous to put this in production without knowing for sure.

@mark.andrews1 I’m curious to see if the update works but I’m intrigued by the number 1 preceding the catalina.org.apache.juli.AsyncFileHandlerin the exception. Did that mistakenly sneak into the Tomcat configuration?

Although a quick search showed some helpful information https://stackoverflow.com/questions/12728147/error-in-eclipse-tomcat-setup-classnotfoundexception-1catalina-org-apache-jul

1 Like

@Jeanie_Swan, sadly the updated agent has made no difference. The ‘strange’ class names are part of the apache.juli logging configuration, yes they look odd, but actually they are fine. we have used this configuration, previously with no issues, either for tomcat or the newrelic agent! A logging.properties file is required on the classpath to configure the logging handlers. But not sure why the new relic agent would care, or why the agent would cause an issue with this?

Currently, in production we are using Tomcat 8 and an earlier version of Liferay, these are the only two significant changes to the setup.

I have some full log files, our .yaml file, but I can’t upload them to the forum!

Hey @mark.andrews1,
I’m going to open a ticket so we can look at logs if needed. However, I’m also providing some initial thoughts here that may solve this one.

In the log excerpt above, we can see that the application is still trying to use java.util.logging. This suggest that something in the application is still using the java.util.logging package from the JRE rather than JULI package. Can you do a ps -ef | grep java and inspect the arguments running for the java process? You should see the argument below. I’m wondering if this argument was maybe set in your previous version catalina.sh (or in some other spot during startup) and was possibly left out when the upgrade happened (This arg setting is in addition to the properties setting for the handlers).

-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

I’ll open a ticket directly from here, so you should see an email come through.

Hey @bellis

Thanks for your reply…

This is what the args look like, so we have the bits you’re referring to

Thanks

Hey @mark.andrews1,

I see you in a ticket with us (ticket ID: 394691). We’ll keep this conversation over there, but please come back to update this thread with the resolution when you get one.

Cheers

I kept assuming this was a config issue so this took longer than it should have. This actually looks exactly like this JDK bug.
https://bugs.openjdk.java.net/browse/JDK-8195096
The stack traces are identical.

The odd thing is that this bug report says it was introduced in 10. But, I’m guessing this existed in 8 as well as it was uncovered by how Tomcat started "reusing the “.handlers” property, to specify class names in a format that the LogManager cannot understand."

I’m thinking this should be submitted to OpenJDK. There might be an existing report, but I didn’t see it linked and couldn’t find it.

It may be worth trying the latest 8 build.

This other report was linked in a comment in the bug report:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/050989.html

1 Like

@bellis - This is strange! We are using the same VM for an earlier version of Liferay, and we do not get this issue!

We just want to use the product that we pay for, for monitoring our site when we go live in June!

Mark

Hello @mark.andrews1, I believe there has been some information/logs requested over the ticket to investigate the issue further. Please share the solution for others when the issue gets resolved. Cheers

Hi there, we’re facing the same issue. Have you find a solution? Our install uses Atlassian Jira with Tomcat 8.5.42 and agent 6.0.0. (JRE 1.8.0)

@eduard4 Welcome to the community! Sorry to hear you are experiencing a similar issue. Given the age of this thread I would suggest creating a new topic if there is no response regarding a solution soon.

I have the same problem with latest NR Java agent v6.2.0. The problem only started when the agent was added to the application. There was no error before.

Can’t load log handler “1catalina.org.apache.juli.AsyncFileHandler”

java.lang.ClassNotFoundException: 1catalina.org.apache.juli.AsyncFileHandler

java.lang.ClassNotFoundException: 1catalina.org.apache.juli.AsyncFileHandler

Hello @szd2013,

I wanted to reach out regarding this error because I realize the final solution wasn’t posted!

Our Engineer’s dug into this and the error is coming from an apache log4j class, which we shadow into the new relic jar:

com.newrelic.agent.deps.org.apache.logging.log4j.core.config.plugins.util.PluginRegistry.

This means that the log4j class is repackaged under the “com.newrelic.agent.deps” prefix. Therefore, this stack trace is coming from apache log4j , but just happens to be repackaged in New Relic’s Java agent jar.

This behavior is caused by an OpenJDK bug described here: https://bugs.openjdk.java.net/browse/JDK-8195096

Exceptions while creating Handlers are trapped and ignored. Therefore the only visible consequence for Apache Tomcat should be the error message on the console…

Basically, the error should be fine to ignore so long as the application is working. :slight_smile: