Hi tison, Do you have plans to:
1. support configuring logforth at runtime using a configuration file? 2. provide a way for a user to add a custom Appender/Layout/Filter? I believe support for runtime configuration using a file would align logforth more closely with current Apache Logging libraries and support for customization would ease some pressure on the core library maintainers. Regards Stephen Webb PS: I have read your helpful post on logforth and educated myself a little on Rust (I have not used Rust) so think the above features would not be a problem in Rust. On Thu, Nov 27, 2025 at 2:52 AM tison <[email protected]> wrote: > > 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 >
