Develop Reference

Logback-classic 1.2.8 DBAppender Missing

I'm trying to upgrade the logback-classic library from version 1.2.3 to 1.2.8. The patch notes say that all DB related code has been removed, so the main DBAppender class no longer exists in the new version https://logback.qos.ch/news.html. Has anyone found some kind of upgrade guide or know of a workaround solution?

Please see https://logback.qos.ch/news.html.
2022-04-20, Release of logback.db version 1.2.11.1
As of logback version 1.2.8 DBAppender no longer ships with logback.
However, DBAppender for logback-classic is available under the
following Maven coordinates:
ch.qos.logback.db:logback-classic-db:1.2.11.1
and for logback-access under
ch.qos.logback.db:logback-access-db:1.2.11.1
Both of these artifacts require
ch.qos.logback.db:logback-core-db:1.2.11.1 which will be pulled in
automatically by Maven's transitivity rules.

I was wondering the same thing after upgrading spring to the 2.6.3 which pulls in logback version 1.2.8+ through spring-boot-starter-logging dependency.
According to logback's site: https://logback.qos.ch/news.html in version 1.2.8: "2) we have removed all database (JDBC) related code in the project with no replacement."
My logback xml configuration file has a custom DB Appender in it and the application failed to build with the following error:
Could not create an Appender of type [ch.qos.logback.classic.db.DBAppender]. ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type ch.qos.logback.classic.db.DBAppender
After doing some research, I found a ticket in the logback backlog with a request to document how to proceed. https://jira.qos.ch/browse/LOGBACK-1609
Apparently the DB appender was removed due to a vulnerability.
According to the developer: "The source code is still there. Until this issue is resolved, you can fetch the code from tag 1.2.8 and rebuild. The DBAppender issue is a bit more complex than what people think. As you can imagine, we have a lot on my plate these days but we'll get to it eventually."
So it sounds like the code was removed while they work on a fix and support will be added back eventually. I wouldn't count on a quick fix though.
As a workaround I have pinned the logback version in my projects gradle file so that I can use the latest version of spring along with the latest version of logback that still supports the DB appender class.
Here is the syntax I used:
ext['logback.version'] = '1.2.7'

OWSAP ESAPI logging support in logback in spring boot

Is there OWSAP ESAPI logging supported in logback for spring boot application? I did a lot of research but could not find much on this. I found out that org.owasp.esapi now supports this after this PR . But this means that I will have to do away with logback. Is there a way that I can implement OWSAP ESAPI logging using logback? We are using slf4j logger that logback provides.
I looked at logback's maven page and there has not been any major release since 2017. So I am guessing that logback does not supports OWSAP ESAPI logging. Please correct me if I am wrong. If that is the case are there any alternatives I can use?
Also according to this spring-boot does not support slf4j 1.8 and above.If that is the case are there any alternatives I can use?

I found out that org.owasp.esap actually delegates the actual logging to our existing infrastructure. So all I had to do is add the correct package and it automatically takes care of the logging via whatever config I have in logback.
Add the esapi dependency to pom.xml
<dependency>
<groupId>org.owasp.esapi</groupId>
<artifactId>esapi</artifactId>
<version>2.2.0.0</version>
</dependency>
Add the ESAPI.properties file to src/main/resources/. This file contains the config properties for the ESAPI logger. Since I was using Slf4j looger, I set ESAPI.Logger=org.owasp.esapi.logging.slf4j.Slf4JLogFactory in the file.
Now we can use the ESAPI logger for logging which internally will use the Slf4j logger. As the function definition of the ESAPI logger has an extra argument I had to update all the logger functions accordingly.

For me, the solution was:
Add the next code to my pom.xml
<dependency>
<groupId>org.owasp.esapi</groupId>
<artifactId>esapi</artifactId>
<version>2.2.0.0</version>
</dependency>
Add ESAPI.properties and validation.properties files to src/main/resources/, I took them from this post, of Vaquar Khan answer.
Update the property ESAPI.Logger in the file ESAPI.properties with this code of AshwinSreekumar:
ESAPI.Logger=org.owasp.esapi.logging.slf4j.Slf4JLogFactory
I hope it will help you, because in my case, I had to do some extra steps to make it work.

Ignore dependency log4j.properties

I have a web application deployed on WildFly 10. After adding a new Maven dependency to my application, logging stopped working. Investigating, I've found that the new dependency includes a log4j.properties in its JAR, and I guess this is causing the logging to screw up.
I cannot delete the file from the JAR, since every time my project compiles it would come back. I need WildFly to manage the logging properties, so adding an additional log4j.properties isn't an option (it would be if it can be configured to fallback to WildFly defaults, but I don't know if this is possibile).
How can I ignore a dependency's log4j.properties or override it with WildFly's settings?

If your app does not use is own log4j properties file or xml, you are best just disabling the per-deployment logging configuration option on wildfly, then any will be ignored

You can exclude Logging module from you jar.
dependencies {
compile group : 'com.chapter1' name: 'common.all', version: '1.0.001'{
exclude( // here u can exclude that module... )
}

In WildFly 10 you can set the use-deployment-logging-config on the logging subsystem to false which will skip processing any logging configuration files. Do note this will skip processing on all deployments.

Log4j2 properties | monitorInterval not working

I am using log4j 2.4 and trying to convert log4j2.xml to log4j.properties, however monitorInterval property doesn't seem to be working with log4j2.properties.
status = trace
name=PropertiesConfig
property.filename = logs
appenders = console, file
monitorInterval=10
though log4j2 following documentation
https://logging.apache.org/log4j/2.x/manual/configuration.html#Properties
clearly stats that
Properties configuration files support the advertiser,
monitorInterval, name, packages, shutdownHook, status
any changes in property file doesn't leads to reloading of logging configuration. On the contrary, it seems to be perfectly working in xml format
<Configuration status="TRACE" monitorInterval="5">
where whenever I do make any changes in .xml my log4j configuration is picked up and is verified via following log.
2016-06-17 14:43:17,267 Thread-5 DEBUG Reconfiguration started for context 1198108795 (org.apache.logging.log4j.core.LoggerContext#86be70a)
2016-06-17 14:43:17,268 Thread-5 DEBUG Not in a ServletContext environment, thus not loading WebLookup plugin.
2016-06-17 14:43:17,273 Thread-5 DEBUG Initializing configuration XmlConfiguration[location=/Users/userx/Desktop/logs/log4j2_prod.xml]
I also tried to upgrade Log4j version to 2.5 but still observe same behavior.

To add to Ralph's answer, this was fixed in Log4j 2.6. The corresponding ticket is https://issues.apache.org/jira/browse/LOG4J2-1263
Please use Log4j-2.6.1 or later.

This was a bug that has been fixed. I would suggest updating the latest log4j release.

Do I need log4j-core when using log4j-core-2.4.1

I am getting the following error:
ERROR StatusLogger Log4j2 could not find a logging implementation.
Please add log4j-core to the classpath. Using SimpleLogger to log to
the console.
I am using eclipse V4.3.2 in a GWT application.
Both log4j-api-2.4.1.jar and log4j-core-2.4.1.jar are on the class path.
I've seen other postings similar to my error but it's not clear to me what I am doing wrong if anything.
Thanks

Classpath is not enough (and actually wrong), you need server code within the WAR's WEB-INF (WEB-INF/lib to be exact here).