Develop Reference

How to configure slf4j (for JDA) to work with log4j (for Minecraft Paper)?

I'm making plugin for Minecraft - 'Paper' exactly. And it uses JDA for Discord bot function.
The problem is, Minecraft(Paper) uses log4j as its logging library. JDA uses slf4j as its logging library. I want JDA to use log4j so that error message of JDA would be shown in console as plugin's error message. (See EDIT2 for actual logs)
No System.out.println() because Minecraft(Paper) will complain about using it.
No Logback because I think it is another logging library, thus it cannot work well with Minecraft(Paper)'s logging system (no JDA logs in Minecraft log etc.). I don't want to implement another logging library when there is already logging system provided by Minecraft, which is log4j.
JDA wiki only describes about Logback so I have to find my own way for making JDA with Minecraft's logging system, but it was no success.
For example:
// Something went wrong in JDA and shows stacktrace
[05:20:26] [Server thread/ERROR]: [MyPlugin] [JDA] 'JDA Error Message'
(prints stacktrace of the error)
// Show debug message of WebSocketClient (Since it is debug message, this can be turned off)
[05:20:26] [Server thread/DEBUG]: [MyPlugin] [JDA] WebSocketClient - Connected to WebSocket
// Show JDA message when JDA bot is loaded
[05:20:26] [Server thread/DEBUG]: [MyPlugin] [JDA] JDA - Finished Loading!
These all messages should be part of the Minecraft(Paper)'s logging system, not mimicing it. This means, it should use JavaPlugin#getLogger().info() or something like this in somewhere of the code.
How to make JDA to be like this?
Just implementing log4j-slf4j18-impl doesn't work. I think I should do something about JDA's logging stuff.
EDIT: Here is current build.gradle file content. LINK
Currently, my plugin implements log4j-slf4j-impl for JDA.

Log4j 2 SLF4J Binding exists for that purpose.
It is an SLF4J logger implementation (like slf4j-simple) that logs everything to log4j. In other words, everything logged with SLF4J will be forwarded to log4j.
In order to use it, just add the following to your pom.xml (see this):
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j18-impl</artifactId>
<version>2.17.2</version>
</dependency>
If you use Gradle, it would look like this:
compile 'org.apache.logging.log4j:log4j-slf4j18-impl:2.17.2'
Adding this dependency includes and automatically registers the logger.

You need to add a "bridge" from slf4j to log4j.
The appropriate dependency needs to fit both the slf4j version and the log4j version.
To find the correct version I checked the build.gradle.kts of JDA
JDA uses the 1.7.25 version of slf4j and your module uses the 2.17.2 version of the log4j.
So you need to add log4j-slf4j-impl.
The log4j-slf4j18-impl is for sl4j from 18 and newer version.
Maven Version
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
<version>2.17.2</version>
</dependency>
Gradle Version
compile 'org.apache.logging.log4j:log4j-slf4j-impl:2.17.2'
Also, making the assumption that your build depends on the JDA, it might be helpful to completely omit importing the SL4J since depending on JDA will make the SL4J available to your plugin.
JDA dependency on SLF4J is declared as an API and therefore is available.
This was also derived from the build.gradle.kts of JDA
So most likely you can safely remove org.slf4j:slf4j-api:1.8.0-beta4 from your dependencies.
Update: for the gradle.build file.
Shadowjar-ing/shading sl4j and log4j might interfere with the initialization process. I could find an occurrence to support this. You could remove all related relocations and try again.
Replace compileOnly('org.slf4j:slf4j-api:1.7.36') with compileOnly('org.slf4j:slf4j-api:1.7.25') to match the version that JDA declares. Most probably this has nothing to do with the error faced.

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.

Log4J2 not set as logger in OSGi environment

I am using commons-logging which should bridge to Log4J2 in an OSGi environment and so have added the dependencies, export-package and import-package in the pom.xml as below but the logger does not get set to Log4J2 logger. No errors are shown but when debugged I found it being set to JDK14Logger.
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.8.2</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.8.2</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-jcl</artifactId>
<version>2.8.2</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>2.8.2</version>
</dependency>
<Export-Package>
org.apache.logging.log4j.*,
org.apache.commons.logging.*
</Export-Package>
<Import-Package>
!org.apache.logging.log4j.*,
!org.apache.commons.logging.*,
*;resolution:=optional
</Import-Package>
[UPDATE]
From the log4j user mailing list I could figure out that due to the non-modular nature of ServiceLoader. I checked out a few usages of ServiceLoader in the OSGi environment to find implementations of interfaces but still couldn't get how this could be gotten to work.
I tried it using pax logging as well but the result is the same except for that the logger is now being set to JclLogger

As Christian said in the other answer, the best fit for logging in OSGI is the pax-logging bundle.
The Pax-logging is built over SLF4J and can be deployed with different possible implementations:
pax-logging-log4j2 (Log4J2)
pax-logging-logback (Logback)
Before we also used pax-logging-service which was using Log4J version 1 but it is not more recommended as the two other implementations works well.
I personally not tested Logback implementation in OSGI, but Log4j2 is working (with some limitations).
One of the good things with this solution is that you must not import any logging implementation on your bundles, the only things have to you do is:
declare slf4j-api as provided dependency (maven scope)
declare eventually the slf4j-simple as test scope in your maven
You don't need to tweak any of the maven-bundle-plugin options regarding logging of any of your bundles.
Here are the step how to do it in ServiceMix version 7.0.1; this release uses originally the pax-logging-services but the next step shows what need to be changed.
By installing the bundles in the startup.properties (immediately after boot time) you ensure that all libs are loaded in the beginning.
These two replace the older version of pax-logging-api and pax-logging-service replaced by pax-logging-log4j2:
mvn\:org.ops4j.pax.logging/pax-logging-api/1.11.13 = 8
mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.11.13 = 8
then in the file: org.ops4j.pax.logging.cfg you mentions just the line:
org.ops4j.pax.logging.log4j2.config.file=${karaf.etc}/log4j2.xml
and add your log4j2.xml file in the ${karaf.etc} folder (installation of servicemix/etc).
You have to copy the libs in the ${karaf.home}/system folder.
This is if you just need a standard log file.
Now come the limitations: if you need to generate your log as json document, I was only able to use the deprecated JSONLayout in the log4j2.xml.
For setting up JSONLayout you can follow my other answer.
In short:
Add the three Jackson dependencies in startup.properties:
mvn\:com.fasterxml.jackson.core/jackson-annotations/2.12.4 = 6
mvn\:com.fasterxml.jackson.core/jackson-core/2.12.4 = 6
mvn\:com.fasterxml.jackson.core/jackson-databind/2.12.4 = 6
and also the pax-logging-log4j2-extra (if you're using log4j2 implementation):
mvn\:org.ops4j.pax.logging/pax-logging-log4j2-extra/1.11.13 = 6
On my version I had to add the three following lines in overrides.properties:
mvn:com.fasterxml.jackson.core/jackson-core/2.12.4;range="[2,3)"
mvn:com.fasterxml.jackson.core/jackson-databind/2.12.4;range="[2,3)"
mvn:com.fasterxml.jackson.core/jackson-annotations/2.12.4;range="[2,3)"
I created a simple docker-compose with a servicemix 7.0.1 on github with the two ways of creating json logs (the new JsonTemplateLayout not working at the moment).

If the above is in your user bundle then this is not correct.
In your user bundle you should simply use the commons logging API and not change the settings of the maven bundle plugin.
It will then create Import-Package statements for the commons logging API but not for log4j which is what you want.
You then should install a suitable logging framework at runtime. I know that pax-logging can handle commons logging in a OSGi compatible way. Maybe plain log4j2 also works but I am not sure.

java.lang.NoSuchMethodError: org.apache.log4j.Logger

We use ivy to manage a multi project java application, and recently this error started showing up when we do builds. What's causing this?

This was fixed by adding the following line to the end of the dependencies section in ivy.xml:
<dependencies>
<exclude module="log4j-over-slf4j" />
</dependencies>
Why was it an issue?
Looks like the log4j bridge for sjf4j has an incomplete implementation
This url explains it in more detail.

It looks like the log4j bridge does not implement the full interface for log4j . If you are still using direct log4j calls, you will need both the slf4j bridge jar and the log4j jar
In your case it looks like you excluded the bridge jar, so all slf4j calls go directly to log4j instead of the bridge.
If your code invokes log4j through the xml file , this will work. However if your code programatically invokes log4j initialization this bridge is not going to work

I know this is a very old question but I wanted to share what worked out fine for me. If you have different artifacts of slf4j-log4j* for two projects that are interdependent on each other, for example spring data jpa and spring MVC, this happens. Keep it consistent or even better have a parent pom. In my case I had slf4j-log4j12 on my spring data jpa project and slf4j-log4j13 on my spring MVC one.

Comment this dependency from the pom.xml
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j13</artifactId>
<version>
</dependency>
And add (or keep) the following one:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.12</version>
</dependency>
Wherever you see a compile time error regarding Log4j, add the following import:
import org.apache.log4j.Logger;