It would be nice if a Jackson implementation of StructuredLogFormatter could be provided by Spring Boot for users that would prefer to use Jackson over Spring Boot's JsonWriter.

Although given that the logging configuration happens very early, it may not be entirely possible to use the application's ObjectMapper bean.

Comment From: philwebb

it may not be entirely possible to use the application's ObjectMapper bean

I don't think it will unfortunately, not without the risk of unwanted side-effects. Out of interest, why would you want to use Jackson? We hoped that way the JSON is written would be an implementation detail that users wouldn't need to worry about.

Comment From: ciscoo

I just wanted to raise the issue early so that the Boot team can make that decision early whether or not it would be provided by Boot. And also extend to others such as GSON.

So then this issue could be used to point back to the reason why it was declined (or not). And allow search.

Currently, my team's APIs don't do any advanced logging or anything really, so Boot's JsonWriter works just fine so far.

Comment From: philwebb

I just wanted to raise the issue early so that the Boot team can make that decision early whether or not it would be provided by Boot. And also extend to others such as GSON.

OK, Thanks! that makes sense.

We did discuss some of this during the preliminary design meetings. Our feeling is that we should offer basic support for ECS and Logstash out-of-the-box, but also allow users to plug-in their own formats if ours aren't working out for them. For the formats we support, we think that the JsonWriter is the correct approach since it supports all that we need and will always produce the same output.

When it comes to developing your own StructuredLogFormatter, you have much more choice because you know the technology you're using. E.g. If you're a company that uses GSON, you're free to using that in your own StructuredLogFormatter implementation. This is similar to the design choice we made to make StructuredLogFormatter take a generic <E> log event type. We've had to develop two versions of each StructuredLogFormatter we support (one for logback and one for Log4j2). We expect that users will have standardized on a single logging system so will only need to develop a single custom StructuredLogFormatter.

So in summary, we're trying to hit a sweet spot where we can provide a good initial experience, but still allow customization. I think that using Jackson or GSON belongs in the customization bucket, so isn't something we should consider right now.