Re: timestamp and thread name in StatusLogger
Thanks for the clarification Ralph. I understand the rationale for unix logs. I believe we should reassess this default for the following reasons: - Users rarely feed service app logs to system logs. Those who do, simply ingest lines intact without any timestamp prefixing. - I have never seen a single logging pattern/configuration without a timestamp. StatusLogger is the only outlier I know of. - Since feeding Log4j to system logs constitute a minority of the use cases, I doubt if we should adjust the default according to that. (That is, people mostly either write/rotate to files via Log4j or send over the network to a log sink.) (I am of course biased in my conclusions due to my limited sample space. Please weigh in, if you think otherwise.) Due to reasons I shared above, I suggest changing the default behavior such that StatusLogger renders a timestamp and users can simply disable this, if needed. If backward compatibility is a big concern, I suggest implementing this for 3. On Fri, Aug 26, 2022 at 10:00 PM Ralph Goers wrote: > It does need to be optional. If you are running your app as a service on > Linux/Unix the logs will already contain a timestamp because they get > routed to the system log. So having a timestamp in them makes them ugly for > that case. > > Ralph > > > On Aug 26, 2022, at 5:39 AM, Gary Gregory > wrote: > > > > I've found that odd myself just like Maven output does not contain > > timestamps, might be for "simplest possible output". I'm all for adding > > these. > > > > Gary > > > > On Fri, Aug 26, 2022, 03:36 Volkan Yazıcı wrote: > > > >> Is there any particular reason we don't render the timestamp and thread > >> name in StatusLogger? > >> > >
Re: SLF4J 1.8 and SLF4J 2.0
Can -slf4j18-impl users simply upgrade to -slf4j20-impl without any changes except replacing the relevant dependency? On Fri, Aug 26, 2022 at 9:55 PM Ralph Goers wrote: > Ceki never released a GA version of SLF4J 1.8. Since we are adding > support for SLF4J 2.0 in the next release I would suggest we also remove > log4j-slf4j18-impl. > > Ralph
Re: SLF4J 1.8 and SLF4J 2.0
Hi Volkan, On Sun, 28 Aug 2022 at 21:35, Volkan Yazıcı wrote: > > Can -slf4j18-impl users simply upgrade to -slf4j20-impl without any changes > except replacing the relevant dependency? Are you talking about Maven redirection? Sounds good to me. Piotr
Re: SLF4J 1.8 and SLF4J 2.0
> On Aug 27, 2022, at 3:00 AM, Piotr P. Karwasz wrote: > > On Fri, 26 Aug 2022 at 21:55, Ralph Goers wrote: >> Ceki never released a GA version of SLF4J 1.8. Since we are adding support >> for SLF4J 2.0 in the next release I would suggest we also remove >> log4j-slf4j18-impl. > > I agree. > > With `log4j-slf4j18-impl` gone I would be tempted to call the SLF4J > 2.0 module `log4j-slf4j2-impl`, unless some changes in SLF4J 2.1 will > force us to have `log4j-slf4j21-impl`. I am OK with log4j-slf4j2-impl. Ralph
Re: Stack valued MDC
Hi Ralph, On Tue, 23 Aug 2022 at 08:14, Ralph Goers wrote: > I don’t see that as a problem at all. Log4jLogEvent’s constructor accepts a > List of properties. We use this to inject properties configured on Loggers > into the Context Map of the LogEvent. I see no reason why these key/value > pairs shouldn’t be treated the same way. Thanks, I didn't know about this feature. I didn't find a way of passing a list of properties from a logger to a Log4jLogEvent without extending the `Logger` interface, so I used a simple `CloseableThreadContext#putAll` to inject the values in the context map[1]. Regarding the "enhanced" MDC feature in SLF4J I am more and more convinced that SLF4J's `pushByKey` is the equivalent of `CloseableThreadContext#put` and `popByKey` is the equivalent of closing a `CloseableThreadContext.Instance`. Ceki's `MDC.putCloseable` does not restore the original value upon closure, which is probably the reason he "enhanced" the MDC interface. Anyway I think that either Pierrick's [2] or mine [3] attempt to implement the "enhanced" MDC should solve the problem. This would leave us with the question whether to implement `LoggingEventAware` or not and we fully support SLF4J 2.0. I am not entirely sure if we should allow users to create entire logging events. Piotr [1] https://github.com/apache/logging-log4j2/pull/1024 [2] https://github.com/apache/logging-log4j2/pull/1022 [3] https://github.com/apache/logging-log4j2/pull/1025
Re: timestamp and thread name in StatusLogger
You seem to be forgetting that StatusLogger doesn’t use Log4j Core. It doesn’t write to rotated logs and cannot write to anything over the network. It only supports specifying a simple file name. At work, all my services use Spring Boot. They are configures with a default log4j2.yml that logs to the console until Spring configures logging, at which point we get the logging configuration from Spring Cloud Configuration. All our services run in Linux, so these startup logs are routed to the system log. If status logging is enabled the logs go there too. I do know Spring Boot and Linux are pretty popular so I don’t know how you can make the claim that the minority of users do this. After all, the default location for the status logger is the console (aka system log). Given the above, I am happy with the way things log now. Ralph > On Aug 28, 2022, at 12:27 PM, Volkan Yazıcı wrote: > > Thanks for the clarification Ralph. > > I understand the rationale for unix logs. I believe we should reassess this > default for the following reasons: > > - Users rarely feed service app logs to system logs. Those who do, > simply ingest lines intact without any timestamp prefixing. > - I have never seen a single logging pattern/configuration without a > timestamp. StatusLogger is the only outlier I know of. > - Since feeding Log4j to system logs constitute a minority of the use > cases, I doubt if we should adjust the default according to that. (That is, > people mostly either write/rotate to files via Log4j or send over the > network to a log sink.) > > (I am of course biased in my conclusions due to my limited sample space. > Please weigh in, if you think otherwise.) > > Due to reasons I shared above, I suggest changing the default behavior such > that StatusLogger renders a timestamp and users can simply disable this, if > needed. If backward compatibility is a big concern, I suggest implementing > this for 3. > > > On Fri, Aug 26, 2022 at 10:00 PM Ralph Goers > wrote: > >> It does need to be optional. If you are running your app as a service on >> Linux/Unix the logs will already contain a timestamp because they get >> routed to the system log. So having a timestamp in them makes them ugly for >> that case. >> >> Ralph >> >>> On Aug 26, 2022, at 5:39 AM, Gary Gregory >> wrote: >>> >>> I've found that odd myself just like Maven output does not contain >>> timestamps, might be for "simplest possible output". I'm all for adding >>> these. >>> >>> Gary >>> >>> On Fri, Aug 26, 2022, 03:36 Volkan Yazıcı wrote: >>> Is there any particular reason we don't render the timestamp and thread name in StatusLogger? >> >>
