note to self: squash the commits before moving out of draft state.

@DGuhr LGTM. The config looks great for me.

@DGuhr @pedroigor Quarkus tests are failing in the CI, not sure if it's related with those changes. Maybe it's just the matter of a rebase.

@abstractj it is related. already told pedro not to merge yet, will investigate

@DGuhr I don't really like the color thing to be honest, as folks will enable logging, try to send it somewhere, then discover some issues with it, go back to docs and figure out they can disable color support. What about just removing color by default? Then in the future we can revisit if this is something folks want and rather have that something that can be enabled (instead of disabled)?

@stianst it's a trade-off. the code-change is one line, but let me explain my reasoning for leaving colored console logging the default:

Question for good UX imo is always what would most users want? Not all, but most. This should then be made the default, so they don't even have to think about it.

Different use cases are affected in this particular case:

1. Reading logs when developing
2. Reading logs on console when starting the "on-prem" dist
3. Reading unstructured logs that are sent to ELK or sth (the case the color issue comes from)
4. reading structured json logs sent to elk (in this case color is always off)

and i guess some more i forgot. but the 4 use cases still prove the point:

I think the usecases where colored logs are actually helpful far outweigh the edge cases where you want uncolored console logging as default, because more people will look and read the logs than will try to send them to [centralizedlogging] and having issues.

Lead me to:
colored unstructured console logs => default, because in most cases when you do unstructured logging easy readability is wanted, and most people get good readability ootb.
no color => edge case 3) is possible by using the switch. These fewer people have to look it up. yes.
structured => also available ootb.

So I would vote against making uncolored logs the default.

@stianst it's a trade-off. the code-change is one line, but let me explain my reasoning for leaving colored console logging the default:

Question for good UX imo is always what would most users want? Not all, but most. This should then be made the default, so they don't even have to think about it.

Different use cases are affected in this particular case:

1. Reading logs when developing
2. Reading logs on console when starting the "on-prem" dist
3. Reading unstructured logs that are sent to ELK or sth (the case the color issue comes from)
4. reading structured json logs sent to elk (in this case color is always off)

and i guess some more i forgot. but the 4 use cases still prove the point:

I think the usecases where colored logs are actually helpful far outweigh the edge cases where you want uncolored console logging as default, because more people will look and read the logs than will try to send them to [centralizedlogging] and having issues.

Lead me to: colored unstructured console logs => default, because in most cases when you do unstructured logging easy readability is wanted, and most people get good readability ootb. no color => edge case 3) is possible by using the switch. These fewer people have to look it up. yes. structured => also available ootb.

So I would vote against making uncolored logs the default.

I would believe in most cases in production folks do not read logs locally, and I shouldn't have to troubleshoot an issue with logging to figure out that it's caused by colored logs, to then figure out how to disable that. That is horrible UX IMO, and much worse than a developer not having some pretty colors in the logs.

@stianst let's agree to disagree here. I think we both do our best to provide good ux, based on our experiences, but in the end we are both just guessing here. I will change colors to being disabled by default, and lets see if people then complain or not. ;)

Should we label this an "unbreaking change" or a "breaking change" in the release notes? 😜 (Just joking)

@stianst changed the default to have no colors now.

@abstractj @pedroigor Also found the missing piece to make the tests pass again (missed changing output format value from "plain" to "default" in the internal keycloak.conf when changing it in the propertymapper, this led to weird behaviours over and over). So from my perspective, when the CI gets green, feel free to merge :)

Also agree colors should be disabled by default if that is what makes more sense for production.