Introduction

If by "library name" you mean the JAR or package metadata associated with each stack-trace frame, the default Log4j2 exception converter is not enough. The feature you want is the extended throwable pattern, %xEx, which appends packaging information to exception frames and is useful when debugging classpath conflicts or duplicate dependencies.

Use %xEx instead of %ex

The default %ex or %throwable converter prints a normal Java stack trace. It does not include packaging details. To see the container name or version information attached to each frame, switch the pattern to %xEx.

1<?xml version="1.0" encoding="UTF-8"?>
2<Configuration status="WARN">
3  <Appenders>
4    <Console name="Console" target="SYSTEM_OUT">
5      <PatternLayout pattern="%d %-5level %logger - %msg%n%xEx"/>
6    </Console>
7  </Appenders>
8
9  <Loggers>
10    <Root level="error">
11      <AppenderRef ref="Console"/>
12    </Root>
13  </Loggers>
14</Configuration>

That is the main answer. If the goal is to know which dependency supplied a class in the trace, %xEx is the pattern to remember.

You can also limit how much trace is printed:

<PatternLayout pattern="%d %-5level %logger - %msg%n%xEx{8}"/>

Or filter noisy packages:

<PatternLayout pattern="%d %-5level %logger - %msg%n%xEx{full}{filters(org.junit,org.gradle)}"/>

That keeps error logs readable while still preserving useful packaging details.

Packaging data is not the same as caller location

This is a common source of confusion. %xEx enriches exception frames. It does not tell Log4j2 to print the source location of the logging call itself.

If you want caller information for the log event, use location fields such as:

• '%C or %class'
• '%M or %method'
• '%F or %file'
• '%L or %line'

For example:

<PatternLayout pattern="%d %-5level %C.%M:%L - %msg%n%xEx"/>

That pattern combines caller location with extended exception output. It is useful, but more expensive than a plain logger-and-message pattern because Log4j2 has to inspect the call stack.

The Java code does not change

The application code is ordinary logging code. The difference is entirely in the layout configuration.

1import org.apache.logging.log4j.LogManager;
2import org.apache.logging.log4j.Logger;
3
4public class Demo {
5    private static final Logger logger = LogManager.getLogger(Demo.class);
6
7    public static void main(String[] args) {
8        try {
9            Integer.parseInt("not-a-number");
10        } catch (NumberFormatException ex) {
11            logger.error("Failed to parse input", ex);
12        }
13    }
14}

With %ex, you get a normal exception. With %xEx, the same exception output carries packaging information for the frames, which can help pinpoint classpath issues faster.

Be deliberate about performance

Extended exception output is usually reasonable for error-level logging, because exceptions should be relatively rare. Caller location fields are more expensive and are a bad default for very high-volume logs.

If you use asynchronous logging, location information may also need explicit enabling in the relevant configuration. That is another reason to treat location-heavy patterns as targeted diagnostics rather than a blanket default.

Common Pitfalls

• Expecting %ex to print JAR or packaging information when it only prints a standard stack trace.
• Confusing packaging data from %xEx with caller location data such as %class or %line.
• Assuming shaded or repackaged JARs will always produce clean dependency identification.
• Enabling expensive location patterns on high-volume log paths without measuring the overhead.
• Changing Java logging code when the real fix belongs in the Log4j2 layout pattern.

Summary

• Use %xEx when you want Log4j2 stack traces enriched with packaging or library information.
• '%ex prints a normal stack trace and does not include that extra metadata.'
• Caller location fields solve a different problem from packaging data.
• Extended stack traces are most useful for error diagnostics and classpath issues.
• Keep expensive location-aware patterns targeted rather than global.