> I would love to incorporate a log4rust framework in my toy project > https://github.com/DaanHoogland/mailscrape.
Here is my patch for you https://github.com/DaanHoogland/mailscrape/pull/2 :D Users once told me that env_logger::init() is easy to start, so logforth has a dedicated enhancement to provide a similar one-liner setup. When you need more customization, you can break it down to more concrete setup code. Besides, you may prefer jiff [1] over chrono. But that's off-topic to this thread. [1] https://github.com/BurntSushi/jiff Best, tison. tison <[email protected]> 于2025年11月26日周三 23:23写道： > > > Would you mind sharing your motivation and expectation for this move > > I understand the state you mentioned below this line. > > So far, Logforth has been maintained mainly by me. While it has had 11 > code contributors ever, most of them came and went. Basically, we have > two maintainers (@andylokandy and I). > > The Rust world has several options for logging: tokio-rs/tracing, > env_logger, slog, fern, log4rs, etc. However, none of them fit my > requirements and aesthetic when finding a solution to ScopeDB. > > I like the design of Log4j and Logback, although their dynamic loading > features may hardly be able to be implemented in Rust, their > abstractions are straightforward and easy to extend. I wrote a blog > (in Chinese, you can read it with a translator) about the background > and history of this project [1]. > > [1] https://www.tisonkun.org/2025/08/20/logforth/ > > That said, many of the log libraries mentioned above are "under > maintenance mode," while they are far from a solid, dependable target. > I hope to extend the audience of Logforth and bring the good practices > from existing logging services, like what Apache Logging Services > developed, to the Rust developers. > > I may consider donating Logforth as a standalone project to the ASF > after my self-assessment is clear that there is a small community to > operate it (I'm an Incubator Mentor for a dozen podlings already :D), > since I know the current challenges with Logging Services, as you > mentioned. > > However, you guys have already been doing a great job in this area. So > before I do any other things about ASF + Logforth, why not reach out > to you and ask for your feedback :D > > Best, > tison. > > tison <[email protected]> 于2025年11月26日周三 23:11写道： > > > > > Which companies use it? > > > > I developed Logforth for my cloud database company, ScopeDB [1]. Also, > > other project like databend [2] use Logforth but it's a fork from an > > early version. > > > > [1] https://github.com/scopedb/ > > [2] https://github.com/databendlabs/databend > > > > > What are the deployment contexts? Logger of a service? > > > > Yes. We use it to capture ScopeDB logs for self-observability. An > > analogy of Log4j to ES is precise. For local development, we use the > > stderr appender, and for the online deployment, we're currently > > adopting the otel appender. Other users have reported usage of the > > file appender. We also use Logforth with Fastrace [3] to provide full > > request traces. > > > > [3] https://github.com/fast/fastrace > > > > > Which appenders/layouts are used most? > > > > For local dev and simple deployment, the stderr appender. In the > > ScopeDB deployment, as described above, the OpenTelemetry appender. I > > know some users who adopt the file appender. > > > > When the stderr appender is used, mainly the text layout [4] is used. > > When it comes to file appender, both text layout and json layout [5] > > are common choices. For the otel appender, typically no layout are > > necessary. But we have a MakeBody trait [6] that can be used in > > combination with a layout. > > > > [4] https://docs.rs/logforth/latest/logforth/layout/struct.TextLayout.html > > [5] https://docs.rs/logforth/latest/logforth/layout/struct.JsonLayout.html > > [6] > > https://docs.rs/logforth-append-opentelemetry/0.3.1/logforth_append_opentelemetry/trait.MakeBody.html > > > > The main extension points of Logforth are: > > > > * Filters: as the well-known purpose > > * Appenders: as the well-known purpose > > * Layout: as the well-known purpose, but Logforth makes layout a > > possible config of appenders where dedicated appenders would decide > > whether or not to accept a layout. Because a layout for FastraceEvent > > or Async appender is non-sense. > > * Diagnostic: similar to MDC but in a less global-state way. > > * Trap: Handle errors that should never go to user's call stack. Also, > > only some appenders would opt in to this feature. > > > > Best, > > tison. > > > > Daan Hoogland <[email protected]> 于2025年11月24日周一 14:22写道： > > > > > > Hi, Rust is for me just a hobby, though I would like to incorporate it > > > more into my daily. If this is any barrier for entry add me as reviewer. > > > > > > I would love to incorporate a log4rust framework in my toy project > > > https://github.com/DaanHoogland/mailscrape. > > > > > > greeting, > > > -- > > > > > > From: Volkan Yazıcı <[email protected]> > > > Date: Sunday, 23 November 2025 at 22:33 > > > To: [email protected] <[email protected]> > > > Subject: Re: Request for comment: A Rust logging library that is inspired > > > by Log4j and Logback > > > > > > Hey Zili! > > > > > > It is good to see you at Logging Services! > > > > > > [See my comments inline.] > > > > > > On Sat, Nov 22, 2025 at 5:32 PM tison <[email protected]> wrote: > > > > > > > It borrows many concepts from log4j and logback, and it is used in > > > > production handling millions/s of logs, so IMO it's relatively solid. > > > > > > > > > > Would you mind providing a little bit more context about its usage, > > > please? > > > [I know it is very hard to probe this for F/OSS, but I'd appreciate any > > > information you can provide on this.] Which companies use it? What are the > > > deployment contexts? Logger of a service? (Consider an Elasticsearch > > > cluster logging using Log4j.) Logger of client/server application? > > > (Consider a custom Spring Boot application.) Which appenders/layouts are > > > used most? > > > > > > "millions/s" of logs? Can you quantify this more in detail, please? > > > > > > > > > > I'm considering moving it to the ASF, but I'd first ask for some > > > > logging devs review on the APIs if anyone here has some spare time. > > > > > > > > > > I think Logging Services is certainly the right place to collect feedback > > > on logging system APIs. The community, including maintainers, possesses a > > > wealth of experience on the subject. IMHO, we can indeed support you > > > there. > > > > > > > I'm considering moving it to the ASF > > > > > > Would you mind sharing your motivation and expectation for this move, > > > please? > > > > > > Personally, I'd be very happy to see Logging Services supporting the Rust > > > ecosystem. That being said, AFAICT, 1) we're pretty much understaffed > > > (Log4j PRs are almost always reviewed by only two people, and > > > Log4net/Log4cxx need Java maintainers' +1s to cut releases due to > > > insufficient number of PMC members with .NET/C++ expertise), and 2) none > > > of > > > the maintainers have serious work experience with Rust. Given the current > > > status quo, I am concerned about slowing down the Logforth development > > > (due > > > to ASF release policies taking days to cut a release) and not being able > > > to > > > contribute to the project meaningfully (due to lack of Rust expertise). I > > > am curious to hear your thoughts. > > > > > > Cheers! > > > > > > > > > Daan Hoogland > > > Community Lead > > > s: +44 20 3603 0540 | m: +31 61400 4545 > > > e: [email protected] | w: www.shapeblue.com | t: @shapeblue > > > a: 3 London Bridge Street, 3rd floor, News Building, London SE1 9SG UK > > > > > > > > > Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue is > > > a registered trademark. This email and any attachments to it may be > > > confidential and are intended solely for the use of the individual to > > > whom it is addressed. Any views or opinions expressed are solely those of > > > the author and do not necessarily represent those of Shape Blue Ltd or > > > related companies. If you are not the intended recipient of this email, > > > you must neither take any action based upon its contents, nor copy or > > > show it to anyone. Please contact the sender if you believe you have > > > received this email in error. > > > > > > Find out more about ShapeBlue and our range of CloudStack related > > > services: > > > > > > IaaS Cloud Design Build | CloudStack Consulting | CloudStack Software > > > Engineering > > > CloudStack Infrastructure Support | CloudStack Bootcamp Training Courses
