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 <ralph.go...@dslextreme.com> 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 <garydgreg...@gmail.com> > 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ı <vol...@yazi.ci> wrote: > > > >> Is there any particular reason we don't render the timestamp and thread > >> name in StatusLogger? > >> > >
