Is it safe to use log4j with karate latest version 1.1.0?
Will the log4j vulnerabilities affect the framework? Is there any way to update log4j version to 2.17.0 in the mix?
Karate does not use log4j and uses logback instead. Maybe you are using an old version, so you need to upgrade.
Note that even logback had a vulnerability so you should use Karate 1.2.0.RC2, please find details here: https://twitter.com/getkarate/status/1471710785051103233
Related
We need to migrate to log4j 2.17 if we are using log4j jar, mvn dependency: tree showing only log4j-over-slf4j:jar. so I assume app is safe as it will redirect call to sl4j not to log4j.
Please confirm my app is safe with this jar without any remediation.?
In the SLF4J website, in the Comments on the log4shell(CVE-2021-44228) vulnerability they state that:
If you are using log4j-over-slf4j.jar in conjunction with the SLF4J API, you are safe unless the underlying implementation is log4j 2.x.
So it basically depends on how you're implementing the logs' generation. Slf4j natively uses logback. But to be sure, you can check your pom.xml and see if log4j is mentioned there.
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.
What is the best way to upgrade from log4j 1.x to 2.x
I have an ANT project. I just deleted the old jar and replaced it with the new log4j is that enough ?
Log4j 2 does not use the same configuration file format. However, Log4j 2.13.0 introduced experimental support for some Log4j 1 configuration files. So you have two choices:
Follow the steps outlined at Migrating from Log4j 1.x which involves including the log4j-1.2-api jar and converting your configuration files to Log4j 2 format or
Include the log4j-1.2-api jar but instead of converting your configuration files follow the steps at Log4j 2 Compatibility with Log4j 1
Note that since option 2 is experimental you may have configurations that Log4j 2 cannot handle. If that happens the Log4j 2 team welcomes you to report a Jira issue to determine how the support can be improved.
The maven repo for Log4j
Could somebody tell what is the difference between these 2 apis ? I assume the one without 1.2 suffix is the latest.
Log4j-1.2-api's are bridge api's which is used for making the applications which works on log4j-1.2.xx to work using `log4j 2
More Info
log4j-1.2-api is a brige to let log4j code log to log4j2 logfile. log4j-api is you can use it api in code to log
Log4j documentation says that it supports internationalization, but no where it provides any details of how to achieve that. Has anyone work on this or can suggest something regarding this please?
I never used it but the feature seems to be provided by the Category.l7dlog methods (added in Release 0.8.4 - 2000-05-01).
As I never used it you have to search for more information on your own or switch to an up to date logging framework like e.g. slf4j with better documentation.
Are you familiar with SLF4J? It can work in conjunction with log4j. SLF4J supports localisation built on top the cal10n project.