My project is using log4j2, and everything looks fine until running an application that uses a third party library that uses log4j 1.x. When our application starts, we get an annoying stack trace involving a ClassNotFoundException on org.apache.log4j.ConsoleAppender. I noticed that one of our dependencies has a log4j.properties inside its jar referencing org.apache.log4j.ConsoleAppender, so I'm guessing that's the reason for the stack trace. A couple other dependencies causing this error include most anything using JBoss logging classes, like embedded glassfish and the eclipse persistence packages.
I tried adding log4j-1.2.bridge api jar to the classpath and it had no effect.
It seems a little ridiculous to include both the jars for log4j2 and log4j1.x in our application classpath. Is there any other alternative or fix?
These links provided answers for me:
https://issues.apache.org/jira/browse/LOG4J2-172
https://issues.jboss.org/browse/JBLOGGING-95
It looks like we are using an out-dated version of JBoss logging that doesn't support log4j2. However, I'm still not sure what to do for the one dependency that includes a log4j.properties.
[edit] It turns out adding log4j-jcl-2.0 jar worked for that dependency.
Related
I'm upgrading Log4j-1.2.17 to Log4j2-2.12.2 in my project.
To do that I'm using the log4j-1.2 bridge.
In old version I use property file to configure log4j.
After upgrade everything looks ok, no errors, no warnings. But logs don't appear in file pointed in properties file.
I realized that PropertyConfigurator.class exists in log4j-1.2-api.jar, but methods don't have implementation.
empty PropertyConfigurator.configure(Properties properties)
Can you explain me that?
Which configuration syntax is correct when I use log4j-1.2-api.jar? log4j or log4j2?
Prior to Log4j 2.13.0 log4j-1.2-api only provides compatibility for applications that used the log4j 1.x API for logging. The Log4j 2 configuration is still used as all logging calls are redirected to Log4j 2. So only the Log4j 2 configuration syntax would be valid.
Many of the old log4j 1.x internal classes are also present because many applications were using them in an attempt manually manipulate logging, much of which probably isn't necessary with Log4j 2.
In Log4j 2.13.0 the log4j-1.2-api was extended to provide experimental support for Log4j 1.x configuration files. You would have to compare your log4j 1 configurations with the documentation to determine if that support will work for you. However, the Log4j 1.x PropertyConfigurator still will be a no-op even with the compatibility support.
I am using a jar file given by my client in CQ5.6.1. Some classes in the jar file requires log4j. So I created a Osgi bundle having the client jar and log4j jar files using Eclipse. I installed this into the Osgi Bundles of CQ and activated the bundle. The class from the client jar is correctly invoked from my components jsp, but the client jar is not able to locate the log4j classes. I am getting the error java.lang.ClassNotFoundException: org.apache.log4j.PropertyConfigurator not found. I also tried putting the log4j jar into the install folder under my app\ in CQ, but that also didn't help. I searched in google but couldn't find a suitable solution yet. Any help to resolve is highly appreciated. Thank you.
Your log4j bundle needs to export the org.apache.log4j package, and the client bundle needs to import it. Sling scripts see all exported packages.
You can use the OSGi console at /system/console/bundles to verify that those exports and imports are correct, the client bundle's status page should show that it imports the package from the log4j bundle.
If the exports are correct, the cause might also be some log4j or client code loading the PropertyConfigurator using a thread context class loader (TCCL) or another mechanism that does not play well with OSGi. If it's TCCL you can work around the issues by setting that TCCL yourself around code that loads the PropertyConfigurator.
CQ does provide the slf4j logging APIs out of the box, so if you can convince your client to switch to those that's probably easier.
I have developed small web application using JSF, and i add log4j to handle logging. Everything works perfectly until i implement add web service in my web application. After implement webservice using apache CXF I'm not getting any logs in my log file, but can get logs in eclipse console. I don't know why, it behave like that? My log file simply show messages like
i'm using jdk1.5, log4j 1.2.15 and CXF 2.6.11. Also i was tried some solutions from apache to use log4j instead of cxf default logger. please refer http://cxf.apache.org/docs/debugging-and-logging.html#DebuggingandLogging-LoggingMessages
But recommended solutions are not worked for me. How can i solve this issue?
It is possible that CXF introduces another log mechanism which means adds a yet another logging mechanism, or the imported versions of slf4j/log4j are not compatible.
I would recommend you to check the CXF pom file, and exclude all the log4j/slf4j jar files.
As #Arash said, remove log4j from classpath (if present). Also add the file META-INF/cxf/org.apache.cxf.Logger to the classpath with the following content:
org.apache.cxf.common.logging.Slf4jLogger
Reference: Using SLF4J Instead of java.util.logging
Problem was solved by removing slf4j-jdk14.jar from CXF. Actually Problem is "Class path contains multiple SLF4J bindings". So i removed CXF log4j binding. Now it's working perfectly. Thanks for all.
I get below error and the log files is not created. I know log4j.properties is not being picked correctly
log4j:WARN No appenders could be found for logger
log4j jar is in lib and classpath
log4j.properties is in src folder and gets loaded to classes folder on build
I tried many ways to fix this error like adding services folder with log4j implementation class to fix WAS logging conflict also tried sfl4j
Has anyone found a way to fix log4j issue with WAS7 or later ?
You can troubleshoot Log4J itself by specifying the log4j.debug=true system variable. Then you'll know exactly what's going on with Log4J, internally.
Does your log4j.properties file contain any logger definitions? perhaps you can paste the file here?
I had this same problem (WAS ignoring my META-INF/services/org.apache.commons.logging.LogFactory file).
The problem was solved when I downgraded commons-logging to 1.0.3, to match WAS version. Check this article for more info.
Consider using the Java Logging framework instead, which is built into the standard Java Runtime Environment and requires no additional installations or configuration. The relevant classes are in the java.util.logging package and there is an overview of the process for using them here (it works in a very similar way to log4j).
I'm developing a web application using JSF 2.0, NetBeans 6.9.1, GlassFish Server 3.1, mojarra 2.0.3, and JasperReports 3.7.6. Included in my project library is the jar file "xerces-2.8.0.jar". This file was imported as part of the JasperReports jar file library. Whenever I try to deploy, run, or debug my project through NetBeans, I receive this error:
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory.
After any change in my project my build fails, and I receive the above error, when I try to deploy, run, or debug it. I have to restart the server and run/debug a second time. I've searched the internet and cannot find a solution to this problem. I've looked at the jar file in question, and and DTDDVFactoryImpl does indeed extend from DTDDVFactory - I don't know why I'm receiving this error. While I can eventually get my project running, it would be much nicer if I wasn't receiving this error.
Can anyone please tell me how I can fix this? Do I need to remove this file from my project library? Do I need to update this file with a newer version/older version?
If you provide your own xerces.jar, you have to do that through the Endorsed Standards Override Mechanism (java -Djava.endorsed.dirs=/path/to/xerces.jar), you are not allowed to just add it on the classpath (and will sooner or later run into trouble if you do). Let me explain.
JAXP is the Java API for XML Processing. The creation of JAXP objects (like parsers, XSLT transfomers, DOM Documents) is done through the factory/factory-method pattern so you can plugin a new JAXP implementation (it has to be newer than the one provided in your JRE). Xerces provides (part of) a JAXP implementation and contains endorsed standards (an endorsed standard is a Java API defined through a standards process other than the Java Community Process, see the Endorsed Standards Override Mechanism). You'll run in all kinds of troubles if you don't use the ESOM.
I got this error when using Selenium with Glassfish. I got around it by copying XML jars (xerces-*, xalan-*, xml-apis*, serialize*) from selenium/libs/ to $AS_HOME/lib/endorsed (for Glassfish 2) or to $AS_HOME/glassfish/lib/endorsed for Glassfish 4.