ECS formatter for JUL (java.util.logging)

[redrathnure]

What about idea to implement ECS formatter for JUL (java.util.logging)?

Motivation

there are bunch of old and very old application which use JUL as logging backend. E.g. Tomcat, Tanuki Wrapper and products based on these applications.
Sometimes is it not easy to switch logging framework, sometimes it's not possible to do this at all. But it would be nice to have logs in ECS format and as option (relatively simple?) we may have class EcsFormatter extends java.util.logging.Formatter.

Open Issues

When I tried to implement it I met a few issues:

• there are no file related metainformation (file name, line etc).
• looks like no thread name, only thread ID
• no MDC or something similar concept
• JUL has bit different log levels and looks like we need mapping between JUL and classical DEBUG/INFO/WARN/ERROR vales. The mapping does not look so pretty, but it is work.

So looks like EcsFormatter class may produce ECS-compatible record, but some of feature will be missed and seems some of AbstractEcsLoggingTest unit tests will be failed.

Questions

1. Does it have sense to implement EcsFormatter?
2. If yes, how to deal with test cases from AbstractEcsLoggingTest and not supported features like MDC and file meta information?

[felixbarny]

Adding a formatter for JUL would be a great addition!

there are no file related metainformation (file name, line etc).

No problem. These are optional and off by default anyways.

looks like no thread name, only thread ID

That's a bit sad as I personally find thread names more descriptive but not a bummer either. Just use the field process.thread.id instead.

no MDC or something similar concept

That's not a problem

JUL has bit different log levels and looks like we need mapping between JUL and classical DEBUG/INFO/WARN/ERROR vales. The mapping does not look so pretty, but it is work.

Just use the native JUL log levels, no need to map them. Every framework/language/ecosystem will have their own log levels. So far, log.level is just a string, without any restrictions on the value or a normalized set of log levels.

Does it have sense to implement EcsFormatter?

Yes!

If yes, how to deal with test cases from AbstractEcsLoggingTest and not supported features like MDC and file meta information?

You could either create a subclass of AbstractEcsLoggingTest and move the non-applicable tests there or return a boolean from putMdc, similar to putNdc. Then just skip the relevant tests if the method returns false. For the log.origin test, you could create a protected boolean supportsLogOrigin() method and return false from the JUL test.

[redrathnure]

Great! Will prepare prepare PR today or these weekends.