I support the initiative. At bol.com, we also needed to implement our own Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go and I don't think I will be able to spare time to both learn a new language (even though I am really into learning Go) and maintain such a project. I mean, not that you need my help, but just wanted to share my availability. If I would have time, I would rather clean up Log4j bugs piled up in JIRA.
I also agree with Matt that this would pave the road to standardizing the logging configuration file formats across multiple languages. What I witness most for code — in particular libraries, APIs, etc. — written by programmers whose expertise is actually in another language, that they mostly don't get the language conventions right. For instance, I was horrified many times in the past to read/use Java code written by JavaScript (front-end) developers. These two languages have totally different approaches and (community embraced) conventions that one cannot plug-n-play the mindset of one to another. In conclusion, as far as I know, none of us is programming in Go on a daily basis. Hence, I strongly recommend consulting to experts in this domain before publishing something to the outside world. For one, I am pretty sure there should be Go experts within the Apache community, hence having expert reviews should be relatively easy. Second, Apache has such a good track record in delivering high quality software, even an inferior project might get quite some attraction and we will be bound to maintain it for years. These are my concerns in general. That said, I would be more than happy to ditch off our custom Go loggers with an Apache-approved alternative. On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > The company I work for has started using Go for some of the middleware > components we are developing. I have looked at several logging frameworks > for Go and have not been impressed by any of them. As such, I am > considering starting a project here. The major goals of this would be: > > Use an external configuration (at least JSON and XML). > Allow the configuration to be accessed via HTTP(S) - Spring Cloud > Configuration. > Allow dynamic reconfiguration. > Allow plugins (probably as Go plugins?) > Support for Markers, context attributes, Layouts, Appenders. > > Anyone interested? > > Ralph > >
