Custom logging format

[inad9300]

I would like to minimize logging noise. At the moment, I find that built-in trace formats either contain undesirable information or not enough of it. I would love for it to be a way to specify a custom format.

The closest to my goal is probably the "ENHANCED" trace format, which is the one I have settled on. Here is an example of a log line using that format, when running the application via Open Liberty's Maven plugin:

[INFO] [2026-09-17T08:30:22.989+0000] 00000aab id=         org.example.app.SomeApplicationClass        1 An event worth logging.

Here is what I would ideally like it to become:

[2026-09-17T08:30:22.989] SomeApplicationClass [FINE] An event worth logging.

Some notes:

• The "[INFO]" in every line when using the Maven plugin is misleading, and pointless.
• Having the timezone repeated in every line isn't necessary.
• The thread ID is very rarely useful, so it would be best activated on demand for specific cases.
• Not once have I seen a value for object ID. I don't really know what it is, but I don't think it adds any value.
• The fully qualified class name is often too much, as it's rare to find ambiguity, and it can usually be resolved by looking at the other information.
• I struggle to get used to "1", "2" and "3" to indicate "FINE[R|ST]" logging levels.

I would appreciate if you could look at this and consider either providing finer-grain configuration options for existing formats, or a more flexible way to specify new, custom ones, perhaps with a syntax similar to the pattern descriptions used in the documentation, e.g.

<time stamp> <thread ID> <object ID> <fully qualified class name of logger> <log level attribute> [<method name>] <message>

[fmhwong]

The current log formats were designed for problem determination needs for most customers. Can you elaborate your use case so that we can understand why a custom format is needed?

[inad9300]

Do put me in contact with the customers in need of "class name of logger [...] restricted to 13 characters" (TBASIC format), I would like to have a little chat with them 😄

Jokes aside, in all honesty, I hardly can, other than trying to hammer home the point that noise is, by definition, distracting. "Attention is all you need", and we haven't got that much of it, so to speak. During development and debugging sessions, identifying messages and making sense of sequences of events becomes harder. Note, in particular, how longer lines are more likely to wrap around. In production, hard drives get filled unnecessarily on top of that.

If you think about it the other way around, if the situation was one where we had slimmer logs, what reasons would you have to introduce the prefix [INFO] before every error and warning? How would you justify inserting the sequence id= in the middle of every log line?

One more observation related to the last bullet point of my previous message: when log types are distinguished by a single character, grepping for them can be easily hampered, if your application's output happens to contain those characters (surrounded by spaces, granted, but still).

[fmhwong]

If you see [INFO], you are probably running maven. It was added by maven. The messages in messages.log don't have it.