jboss-logging/log4j-jboss-logmanager

JBoss Log4j Emulation

JBoss Logging

JBoss Logging is a logging facade which can bind to different log managers allowing your applications to be log manager agnostic.

Usage

JBoss Logging is similar to other logging facades in the way you get a logger and log messages. One thing to note is the format style log methods will only format the message if the log level is enabled. This helps with performance of objects which may have complex toString() methods.

private static final Logger LOGGER = Logger.getLogger(Customer.class);

public Customer getCustomer(final int id) {
    LOGGER.debugf("Looking up customer %d", id);
    try {
        final Customer customer = findCustomer(id);
        LOGGER.tracef("Found customer: %s", customer);
        return customer;
    } catch (Exception e) {
        LOGGER.errorf(e, "Error looking up customer %d", id);
    }
    return null;
}

Supported Log Managers

The following are the supported log managers and listed in the order the attempt to discover the provider is done.

1. JBoss Log Manager

2. Log4j 2

3. SLF4J and Logback

4. log4j (note this log manager is EOL’d)

5. Java Util Logging

You can define the specific log manager you want to use by specifying the org.jboss.logging.provider system property. The following is the mapping of the property value to the log manager.

Property Value	Log Manager
jboss	JBoss Log Manager
jdk	Java Util Logging
log4j2	Log4j 2
log4j	log4j
slf4j	SLF4J and Logback

Custom Provider

You can also implement your own org.jboss.logging.LoggerProvider which would be loaded from a ServiceLoader. Simply implement the API and add a META-INF/services/org.jboss.logging.LoggerProvider file with the fully qualified class name of your implementation to your library. If the system property is not defined, your implementation should be discovered.

Maven Dependency

<dependency>
    <groupId>org.jboss.logging</groupId>
    <artifactId>jboss-logging</artifactId>
    <version>${version.org.jboss.logging}</version>
</dependency>

Contributing

See the contributing guide.

log4j-jboss-logmanager's Issues

Disable external entity support for the DOMConfigurator

Disable external entity support fro the DOMConfigurator. The following features should be added to the DocumentBuilderFactory:

• http://xml.org/sax/features/external-general-entities
• http://xml.org/sax/features/external-parameter-entities

Both of the features should be set to false.

Add an exclusion for the SMTPAppender

Add an exclusion to the SMTPAppender as it's provided by the fork.

Upgrade dependencies

Upgrade the following dependencies:

• org.jboss:jboss-parent to 39
• org.jboss.modules:jboss-modules to 2.0.1.Final
• org.jboss.logging:jboss-logging to 3.4.2.Final
• junit:junitto 4.13.2

LoggingEvent can't manage Object Message

Hello,

I'm trying to pass personalized object message throught LoggingEvent and access it in personalized appender.
This works with standard Log4j implementation.
With log4j-jboss-logmanager implementation, LoggingEvent's constructor transforms message parameter from Object to String calling message.toString().
Is it possible to preserve and manage Object type of message parameter in LoggingEvent object ?

Thanks.

Set the mail.smtp.ssl.checkserveridentity to true by default

CVE-2020-9488 will not be fixed for log4j 1.x. Copy in the SMTPAppender and set the property by default.

Related Issues:

• https://issues.apache.org/jira/browse/LOG4J2-2819

Configuration of logback in jboss-logging

ConsoleAppender$SystemOutStream should never close FileDescriptor.out

Hello,
we had an issue with log4j configuration and "stdout not working any more".

Problems:

• you deliver a specific log4j implementation
• which - in contrast to the original one - closes System.out aka FileDescriptor.out

Original Log4j does nothing inside close() but your implementation closes FileDescriptor.out which leads to "System.out not working any more" as FileDescriptor.valid() returns false then.

public SystemOutStream() {
out = createPrintStream(FileDescriptor.out);
}

public void close() {
out.close(); <<<<< this is terribly wrong
}

Remove the JMSAppender

Remove the JMSAppender from this shaded-fork. This is due to https://access.redhat.com/security/cve/CVE-2021-4104. The simplest solution is just to remove the appender as it does JNDI lookups and is likely rarely used.

Along with this the JMSSink should also be removed. This is a standalone entry point which consumes log messages from the JMSAppender. There is no real need to include this.

Remove the JDBCAppender

Remove the JDBCAppender. This is due to https://access.redhat.com/security/cve/cve-2022-23305. This could be fixed with a PreparedStatement, however this is not a true fork of log4j so dropping the appender seems like a safer option.

Remove Chainsaw

Chainsaw is included in log4j 1. It's also a separate project https://logging.apache.org/chainsaw/2.x/. Given the CVE https://access.redhat.com/security/cve/cve-2022-23307 and the fact there is a separate project Chainsaw should be removed from this project.

Log Level Changes from OFF to DEBUG when using Log4j LogManager

Description

When setting the log level to OFF the log level switches to DEBUG when using the Log4j 1.x LogManager in your project.

Looks like maybe it's simply Level.OFF entry is missing in the map here:

log4j-jboss-logmanager/src/main/java/org/apache/log4j/JBossLevelMapping.java

Line 25 in 49d37c3

final Map<java.util.logging.Level, Level> map = new IdentityHashMap<java.util.logging.Level, Level>();

Already forked the project and will test this.

Maybe i can then provide a PR for this.

Here you are:

#32

This works in my tests. Hopefully no other side effects included.

Steps to Reproduce

I set up 2 GitHub projects to show the issue:
https://github.com/cquoss/log4j-log-msg-producer'
This first one is merely to produce log messages using log4j 1.x.
https://github.com/cquoss/log4j-jboss-logmanager-level-off-bug
This second project makes use of the first one. When you build both projects locally and run the test on the second one you will notice these log outputs in file target/test.log:

2022-01-24 18:29:50,250 [log4j] [main] DEBUG de.quoss.test.log.producer.log4j.Log4jLogMsgProducer Log4j Logger Debug message
2022-01-24 18:29:50,295 [log4j] [main] INFO de.quoss.test.log.producer.log4j.Log4jLogMsgProducer Log4j Logger Info message
2022-01-24 18:29:50,296 [log4j] [main] WARN de.quoss.test.log.producer.log4j.Log4jLogMsgProducer Log4j Logger Warn message
2022-01-24 18:29:50,296 [log4j] [main] ERROR de.quoss.test.log.producer.log4j.Log4jLogMsgProducer Log4j Logger Error message
2022-01-24 18:29:50,296 [log4j] [main] FATAL de.quoss.test.log.producer.log4j.Log4jLogMsgProducer Log4j Logger Fatal message
2022-01-24 18:29:50,305 [after] [main] DEBUG de.quoss.bug.jboss.logmananger.log4j.Main JBoss Logger Debug message
2022-01-24 18:29:50,306 [after] [main] INFO de.quoss.bug.jboss.logmananger.log4j.Main JBoss Logger Info message
2022-01-24 18:29:50,306 [after] [main] WARN de.quoss.bug.jboss.logmananger.log4j.Main JBoss Logger Warn message
2022-01-24 18:29:50,306 [after] [main] ERROR de.quoss.bug.jboss.logmananger.log4j.Main JBoss Logger Error message
2022-01-24 18:29:50,307 [after] [main] FATAL de.quoss.bug.jboss.logmananger.log4j.Main JBoss Logger Fatal message

I used MDC qualifiers to tag the log messages. The messages tagged with 'before' are suppressed as expected because of root log level OFF.

But starting with the Log4j 1.x DEBUG log message log messages are displayed again because some malfunction in the code switched the root log level to DEBUG.