In my project we are using SBT. We are not directly using log4j but it's being included; probably because one of the libraries we use requires it.
I'm trying to update the code to not use the vulnerable version of log4j but I have no direct control over this import. Is there anything I can do in the build.sbt file to prevent this?
I guess Gradle has some functionality to force this (step 3 here). Does SBT have an equivelant?
Related
I've followed the doc here : https://logging.apache.org/log4j/2.x/manual/migration.html
Also looked at https://logging.apache.org/log4j/2.x/manual/configuration.html#Properties
My existing log4j.properties only uses DailyRollingFileAppender, ConsoleAppender, both of which are under the 'Supported Components', so I shouldn't be forced to convert my log4j.properties file into log4j2.properties format. I'm not accessing methods and classes internal to the Log4j 1.x implementation, as suggested by the document.
For using the bridge, I previously was using both log4j1.compatibility and log4j.configuration, but the document suggests using 'any one' (tried using just one, doesn't work)
I can build my application successfully, however, my application no longer logs anything. What am I missing?
You may want to consider reload4j as a drop-in replacement for log4j 1.x. Initiated by Ceki Gülcü, the original author of Apache log4j 1.x, the reload4j project is a fork of Apache log4j version 1.2.17 with the goal of fixing pressing security issues.
The reload4j project offers a clear and easy migration path for the users who have an urgent need to fix vulnerabilities in log4j 1.2.17.
You don't need to update your properties file.
You can add a log4j2.component.properties file on the class path (in my case, in the same directory as my log4j.properties file) to set the log4j1.compatibility property, like this:
log4j1.compatibility=true
In our case, it only required setting the compatibility property and then it automatically picked up the log4j.properties file that was available on the class path.
Figured it out.
The answer lied in the Automatic Configuration section
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'm newbie in hybris. I want to add maven dependency in hybris using external-dependencies.xml. But I can't see any of those jar(s) popped-in. Is it possible to get jar using external-dependencies.xml, if yes, please provide your response.
The platform build is coupled with ant but you can use maven dependency (by default is disabled because all necessary libraries are shipped with the hybris).
In order to activate dependency management you have to follow these steps:
1) Make sure you have maven installed
2) Open the extensioninfo.xml from your extension
2.1) Include usemaven="true", for instance
3) Manage your dependencies inside "external-dependencies.xml" file (Inside this file is a regular maven pom.xml)
4) build your project (ant all). Hybris fetch required libraries into \lib and \web\webroot\WEB-INF\lib (Bear in mind that there are two "external-dependencies.xml", one for the core module and other for the web module)
Besides if you look the ant targets you will see there is one call "updateMavenDependencies". This task delete all jars in the lib folder and replaces them with the defined maven dependencies. In case you dont want maven to manage a few libraries you can handle this, creating a file in the root of your extension call "unmanaged-dependencies.txt".On this file you will include all libraries maven is not going to manage (therefore the ant target is not going to delete the libraries include on this file)
My official answer: add usemaven="true" in your extensioninfo.xml (extension tag)
I'm newbie too to Hybris but what I know is that whenever you need a dependency in a Hybris extension you need to add the name of the dependency to hybris/config/localextensions.xml and in extensioninfo.xml in the extension you want to add the dependency.
As for the Maven dependency, I'm not sure how to do that because I mostly use the out-of-the-box build system which is based on Ant.
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.
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).