On 18/3/20 2:57 pm, Brian Burch wrote:

I have done quite a lot of experiments, but I will stick to the case which appears to have produced the most encouraging(!) results.

I stumbled across https://logging.apache.org/log4j/2.x/log4j-appserver/index.html.

This short page has significant overlap with your suggestions, but there are differences too. I'll compare both before I say much more.

Your setenv puts log4j-api-2.13.1.jar on the classpath, but this file does not exist in my log4j2 binary download.

Following their advice, I first tried replacing it with log4j-appserver-2.13.1.jar, but startup failed with ClassNotFoundException.

Then I added (not replaced) log4j-1.2-api-2.13.1.jar, which seemed to be a good guess. That failed as follows:

Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: org.apache.juli.logging.LogConfigurationException: java.lang.reflect.InvocationTargetException at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:136) at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:153)
        at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:208)
at org.apache.catalina.startup.Bootstrap.<clinit>(Bootstrap.java:51)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:134)
        ... 3 more
Caused by: java.lang.NoClassDefFoundError: org/apache/logging/log4j/LogManager
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at org.apache.logging.log4j.appserver.tomcat.TomcatLogger.<init>(TomcatLogger.java:67)
        ... 8 more

However, I suspected my "current best effort" had disabled the internal tomcat logging (juli) but failed to enable log4j2. The message I quoted from catalina.out looked suspiciously like it had been handled by the jvm Logger, which is consistent with your suggestion
> I tried building log4j2 from source and gave up. It is a bit of a
nuisance that my development system uses both OpenJDK 8 and 11 because I keep forgetting which is required by my different projects. The log4j2 toolchains requirement for java 9 was just too much to contemplate!

Clearly, adding log4j-1.2-api-2.13.1.jar did something significant, but I guess the jar is incompatible in some manner?

I recall the log4j2 pom.xml has a java.target of 1.7, as well as its toolchain requirement for java 9. I'm doing my very best to build and run tomcat under java 8. Is this relevant, or just a red herring?

I downloaded the apache-log4j-2.13.1 binaries, so I will deploy those jars in my tests.

I needed to make some minor tweaks to your setenv.bat before I had a syntax-free setenv.sh. Of course, I also replaced your ${CATALINA_BASE} with ${CATALINA_HOME} because that's where I'm currently putting the logging jars.

That bootstrap directory also has a copy of tomcat-juli from my java 8 build from 5.8.53-dev source:-

-rw-r--r-- 1 tomcat8 tomcat8   51224 Mar  9 17:24 tomcat-juli.jar

I also noted from the web advice above that log4j2 looks for it's configuration file under the name log4j2-tomcat.xml, not log4j2.xml. I'm not keen on the advice to deploy the jars to new tomcat directories called catalina.home/log4j2/lib and ./log4j2/conf, so I favour your suggestion of using catalina.home/bin for my first tests.

Oh yes...

It didn't make any difference whether I called my configuration file conf/log4j2.xml or conf/log4j2-tomcat.xml.

I don't think it should matter that the default conf/logging.properties does not exist... wdyt?

I really appreciate your thoughtful advice. It would be useful for me to pare the advice down to its essentials and then update the tomcat 8 wiki advice.

So, to summarise, I've eliminated a lot of possible solutions and changed the failure symptoms considerably. Unfortunately, log4j2 logging doesn't seem to be loaded successfully.

I'm in Australia, so I've run out of time for the day. I'd love to hear that I've just messed up something simple, but if not, even an intelligent guess would be helpful because I feel I've run out of ideas.



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

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

Reply via email to