We Keep Coding

log4j1 to log4j2 bridge autoconfiguration is not being created

I followed steps for migrating log4j1 to log4j2 using bridge, https://logging.apache.org/log4j/2.x/manual/migration.html
The thing is it doesn't create automatic configuration even if I set the system property of log4j1.compatibility = true. I don't have idea what is happening because the console doesn't even show any errors that configuration file is missing.
Extra information:
It stopped logging when I replaced log4j 1.2.16 by these three jars
log4j-1.2-api-2.17.1
log4j-api-2.17.1
log4j-core-2.17.1

Force a specific logger in Spring Boot

We wanted to switch from standard logback to log4j in Spring Boot 2.4.x.
For most modules, it is a no-brainer by simply removing the dependency of logback, but there are some modules, which are using pact-jvm as a shadow-jar dependency to be able to create the pact files from unit tests.
Now the odyssey begins, because pact needs logback and with the pact-jar on the classpath Spring recognizes the logback class it is looking for and decides to use logback instead of log4j as the logger in the tests.
Is there a possibility to create something like a log bean or a hidden configuration, which allows forcing Spring to use log4j instead of logback, also if logback is on the classpath?
Pact should not be an issue at this point, because the server is started as a standalone server from gradle. We only require the dependency to be able to start everything and to have the classes available.
Thanks!

You may follow these steps to configure log4j with spring boot
Add the log4j dependency to your module
Create logger object in your respective class and use the logger object to log the messages.
org.apache.log4j.Logger logger = org.apache.log4j.Logger.getLogger(<YourClassName>.class);
In your spring boot module/project add log4j.properties file in resources so that this will be available on class path at runtime. Following is sample content for the log4j.properties
log4j.rootLogger=INFO, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
Make sure that the spring boot module bundles the log4j jar when you build.
Once spring boot finds the log4j jar and the log4j.properties on the class path it will be able to initialize the log4j logger for you.

Yes, that's clear. The issue is, that Spring Boots Autoconfiguration is loading the logger for slf4j (sorry forgot that). So here it iterates over the supported candidates in the order:
logback
log4j
apache-log-commons
And it seems that it does not look for beans, it simply looks for the classes by reflection.
If we now start the app for testing together with pact server, Spring Boot resolves an Append* class and thinks, that this has to be the logger of our choice.
It creates the logback instance, which is searching for its config, but then it fails, because the config is for log4j.

Configuring Spring Boot Logback

I am trying to write the application.yml file with the logging configurations for spring boot. Thanks to Bal from my previous question I was able to take a look at the sample file on spring boot's website. Since I only want to configure the logging information for now here is what my yml file looks like right now:
# ===================================================================
# SPRING BOOT PROPERTIES
# ===================================================================
# LOGGING
logging:
config: /logback.xml # Location of the logging configuration file. For instance `classpath:logback.xml` for Logback
logging.level.org.springFramework=DEBUG # Log levels severity mapping. For instance `logging.level.org.springframework=DEBUG`
path: # Location of the log file. For instance `/var/log`
pattern:
console: # Appender pattern for output to the console. Only supported with the default logback setup.
file: # Appender pattern for output to the file. Only supported with the default logback setup.
level: # Appender pattern for log level (default %5p). Only supported with the default logback setup.
But I have a few questions:
How much logging configuration should I do here in the yml file versus the logback.xml file? Should any logging configuration be put here at all versus putting it all in logback.xml?
Is the logging level configuration line written correctly?
Can I use another library's logging level, like logback? For example, could I put this: ch.qos.logback.classic.Level=DEBUG

I would not combine logback.xml with application.yml. Use either simplified configuration via application.yml if it is enough for you or use "fullfeatured" logback.xml.
To be honest I am not sure what will happen when you will have contradicting configuration in those two files (e.g. different patterns or log levels).
2 + 3. My guess is you have extra logging part. Correct example would be e.g.
logging:
level:
ch.qos.logback.classic: DEBUG
org.hibernate: INFO

How do I control logging in 3rd party libraries

I have a Tomcat server running a Spring-based servlet.
I've set up [project root]/src/log4j.properties file as below:
# Root logger option
log4j.rootLogger=WARN, stdout
# Redirect log messages to console
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%-5p %d{HH:mm:ss} %m [%c{3}:%L]%n
log4j.logger.com.martincarney.bugTracker=DEBUG
log4j.logger.com.martincarney.bugTracker.controller=ERROR
This correctly logs my own code just fine, but doesn't seem to have any effect on logging from within the various libraries I'm using. For example, I still get INFO logs from org.apache.* to the Eclipse console error stream during Tomcat startup, even if I add log4j.logger.org.apache=WARN to my log4j.properties.
I'm using slf4j-api and slf4j-log4j jars, obtained through Maven.
How can I take control of logging levels and targets outside my own code?

Some libraries use other logging frameworks like java.util.logging.
You could redirect logging with SLF4J, see SLF4J - Bridging legacy APIs:
Redirection for Jakarta Commons Logging:
To ease migration to SLF4J from JCL, SLF4J distributions include the jar file jcl-over-slf4j.jar. This jar file is intended as a drop-in replacement for JCL version 1.1.1. It implements the public API of JCL but using SLF4J underneath, hence the name "JCL over SLF4J."
Redirection for java.util.Logging (SLF4J API):
Installation via logging.properties configuration file:
// register SLF4JBridgeHandler as handler for the j.u.l. root logger
handlers = org.slf4j.bridge.SLF4JBridgeHandler
For configuration of java.util.Logging see JUL API.
Some libraries like Apache CXF supports more than one logging framework, see Apache CXF - Debugging and Logging .

How to make slf4j print its own configuration?

log4j has a system property called log4j.debug, that when set by adding -Dlog4j.debug=true to your command line, prints out the information about how log4j configures itself (for example, the location of the con file it found and loaded).
I am looking for a similar capability for slf4j. Can we tell slf4j to print out how it is set and configured?

slf4j is wrapper for other loggin systems (the f in the name stands for facade), it does not have its own configuration.
With slf4j you can even use log4j as real logging library. If you are using logback as logging library along with slf4j there is an attribute debug for the main configuration tag (if you are using an xml file for configuring logback).
<configuration debug="true">
....your conf here
</configuration>
the logback mnanual can be found here