Hi Stephen, Thanks for your feedback!
> 2. provide a way for a user to add a custom Appender/Layout/Filter? Sure. Actually, currently the final logforth bundles many appenders/layouts from separated crates. You can see [1] and [2]. [1] https://github.com/fast/logforth/tree/main/appenders [2] https://github.com/fast/logforth/blob/66d2a47299a2609a7154b0737740f60ce18ad944/logforth/src/lib.rs#L73-L96 Logforth provides Appender/Layout/Filter (and Diagnostic/Trap) traits (like Java interfaces in some ways) so custom implementations can implement those traits and then pass them to the logger constructor. You can take [3] as an example. Perhaps I can add more examples and move them to a top-level "examples" dir. [3] https://github.com/fast/logforth/blob/66d2a47299a2609a7154b0737740f60ce18ad944/logforth/examples/custom_layout_filter.rs > 1. support configuring logforth at runtime using a configuration file? It's possible to configure Logforth at runtime, in a programmatic way, like [4]. [4] https://github.com/scopedb/percas/blob/89e23e9e46d2ee169f44e0542f2e2ddae8fafe62/crates/server/src/telemetry.rs#L131-L227 Since it reads from a config file "config.toml", I'd expect this is what "configuring logforth at runtime using a configuration file" means. However, I know that Log4j and Logback each define their own dedicated configuration file. Log4rs attempted something similar [5]. But I'd say since Rust is more static while Java can dynamically load classes and more, perhaps a customized config file like [4] and user-defined loading logic would be more proper in Rust. [5] https://github.com/estk/log4rs/blob/2e6dee8b10b54d9ddfef50aeed1bee5a1fd47e93/docs/Configuration.md I remember that log4cxx implements some dynamic features in this part. I'm glad to learn from it and see if logforth can leverage what log4cxx does. Best, tison. Stephen Webb <[email protected]> 于2025年12月2日周二 10:05写道： > > 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 > >
