Split and modernize JANSI support.

[ppkarwasz]

This PR:

• Adds a new ConsoleStreamProvider plugin type that can decide how the Console Appender stream is built.
• Moves JAnsi support to a new log4j-jansi module.
• Upgrades the JAnsi library to version 2.x Replaces JAnsi with JLine 3, since JAnsi is deprecated (cf. Archive this repository, Jansi is part of Jline3 now fusesource/jansi#294).
• Rewrites JAnsiTextRenderer to use our internal AnsiEscape utility.

Fixes #1736.

[ppkarwasz]

This is blocked by #2691: if the TextRenderer interface is removed from the %ex pattern converter, the JAnsiTextRenderer can be removed, otherwise it should be kept.

[ppkarwasz]

I rewrite JAnsiTextRenderer to use our internal AnsiEscape ANSI sequence generator, instead of relying on JANSI.
Cf. 5ae37df

[garydgregory]

Module should not be named "log4j-jansi" since the PR no longer uses JAnsi. How about "log4j-ansi"?

[ppkarwasz]

Module should not be named "log4j-jansi" since the PR no longer uses JAnsi. How about "log4j-ansi"?

The module uses org.jline:jansi-core instead of org.fusesource.jansi:jansi, so I believe the name is appropriate.

The JAnsiTextRenderer (which is part of log4j-core, not log4j-jansi) effectively could be renamed AnsiTextRenderer. Keeping the same name, however will allow me to backport part of this PR to 2.x.

[garydgregory]

@ppkarwasz
TY for the explanation: -)
+1

[vy]

See my remark about removing the JAnsi support, completely.

This is blocked by #2691: if the TextRenderer interface is removed from the %ex pattern converter, the JAnsiTextRenderer can be removed, otherwise it should be kept.

#2691 cannot remove anything, since it is against 2.x. But be my guest to completely remove it while porting it to main. Hence, I see two paths we can take:

1. Wait for Consolidate stack trace rendering in Pattern Layout #2691 to get merged to 2.x, port it to main, and then remove TextRenderer in main.
2. Remove TextRenderer in main without waiting for Consolidate stack trace rendering in Pattern Layout #2691.

[@alan0428a, I am CC'ing you, in case you're interested in.]

[ppkarwasz]

See my remark about removing the JAnsi support, completely.

This is blocked by #2691: if the TextRenderer interface is removed from the %ex pattern converter, the JAnsiTextRenderer can be removed, otherwise it should be kept.

#2691 cannot remove anything, since it is against 2.x.

Of course you can not remove it, but as far as I can tell, you are bypassing it. Since ThrowableProxy and related classes are not used any more, TextRenderer isn't used either. Am I right?

[ppkarwasz]

Note that in this PR we are discussing 3 related, but distinct features:

Enabling ANSI escapes on Windows terminals

This feature is probably useless and can be dropped. It requires the JAnsi library.

Detecting if the console is a terminal

The JAnsi library is very good at it. It can detect separately if stdout and stderr are TTY devices on UNIX or character devices on Windows. If the stream is not attached to a TTY, the ANSI escape sequences will be dropped.

In Log4j Core 2 we emulate this behavior by checking if System.console() exists (cf. noConsoleNoAnsi. Iit exists if both stdin and stdout are connected to a terminal). Java 22 adds a new Console.isTerminal() method, but I am unsure how it works.

Coloring of stack traces and messages

In Log4j Core 2, JAnsi was also used to color stack traces and messages. This is enabled by adding ansi as an option to %ex, %xEx, %rEx or %m. The JAnsi library is not needed for %style or %highlight.

This PR rewrites JAnsiTextRenderer to work without JAnsi.

[ppkarwasz]

@garydgregory,

How do you feel about removing JAnsi (but not ANSI) support as a test? For this PR it would mean:

• I remove the log4j-jansi module,
• I keep the modifications to JAnsiTextRenderer and I port them to 2.x.

[garydgregory]

Hi @ppkarwasz

ATM, I only care that my Log4j 2 XML configurations don't break and keep their current colorized output. However that happens should be an implementation detail.

[ppkarwasz]

@vy,

Should I port the changes to JAnsiTextRenderer to 2.x? It was used to support the ansi option in the %m, %ex, %xEx and %rEx pattern converters. Now only the %m{ansi} pattern converter requires it.

[vy]

Should I port the changes to JAnsiTextRenderer to 2.x? It was used to support the ansi option in the %m, %ex, %xEx and %rEx pattern converters. Now only the %m{ansi} pattern converter requires it.

@ppkarwasz, yes, please do so.

Curious: Does that translate to no JAnsi dependency on 2.x?

[ppkarwasz]

Curious: Does that translate to no JAnsi dependency on 2.x?

Are you suggesting we drop an end-of-life dependency (Jansi 1.x) released by a project that does not exist any more (Jansi, which was replaced by JLine) and break backward compatibility for Windows platforms older than 2017? 😛

Windows 7 and previous releases have a 3.5% market share, so I think we could do it.

[vy]

Are you suggesting we drop an end-of-life dependency (Jansi 1.x) released by a project that does not exist any more (Jansi, which was replaced by JLine) and break backward compatibility for Windows platforms older than 2017? 😛

Windows 7 and previous releases have a 3.5% market share, so I think we could do it.

@ppkarwasz, yes, let's please indeed drop the JAnsi dependency.

[ppkarwasz]

Done in #3070