On 18/3/20 2:57 pm, Brian Burch wrote:
<snip>
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.
Brian
Brian
---------------------------------------------------------------------
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
