Any good ways to filter common concurrency framework lines from stack traces?

Matt Sicker <[email protected]> Wed, 4 Jun 2025 12:01:43 -0500
Newsgroups gmane.comp.jakarta.log4j.user
Message-ID <[email protected]>
--Apple-Mail=_B94BDF43-E3DC-4775-A527-6926A1DC2F29
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

For example, in the simple case, suppose I=E2=80=99m using =
CompletableFuture and the value times out with a TimeoutException. This =
stack trace will include tons of entries for =
java.util.concurrent.CompletableFuture related to the transformation =
pipeline leading up to that point (i.e., transforming CompletableFuture =
instances creates a complicated call stack as an implementation detail).

Suppose we then combine some combination of other typical libraries like =
resilience4j, failsafe, spring-retry, micrometer, open telemetry, and =
then integrate with some asynchronous things like netty, reactor, Kotlin =
coroutines, various thread pools and queues, and potentially even some =
sort of context propagation wrappers. In the end, I get a stack trace =
that=E2=80=99s about 200% longer than necessary. IDEs seem to have a =
feature that can collapse these sorts of common parts of the stack trace =
for comparison.

While I have found that the throwable converter pattern [1] supports =
filtering by a list of package names, this may be overly broad for my =
use case here depending on the structure of the library I=E2=80=99m =
trying to filter out.

[1]: =
https://logging.apache.org/log4j/2.x/manual/pattern-layout.html#converter-=
exception


--Apple-Mail=_B94BDF43-E3DC-4775-A527-6926A1DC2F29--