One thing I think we don’t do enough is “advertise” Log4j as “Enterprise Ready” or “Enterprise Class”. Logback may be popular with open source projects but it is missing a lot of features that make it useful for use in an enterprise. For example, I know of no out-of-the-box way for it to utilities a centralized configuration as I do with Log4j 2. I would like to see the bullets of features on the home page organized under sections like that. For example,
Log4j is designed to support Enterprise applications utilizing a modern distributed architecture: Built in support for utilizing a centralized configuration such as Spring Cloud Configuration Server Built in support for logging from containers to an ELK stack using JSON. Dynamic enablement of debug logging for specific users, accounts, or other events. Log4j has built in support for real-time applications: It can be used in a garbage free manner to eliminate garbage collection pauses. It provides asynchronous logging to eliminate pauses in the main application threads. etc. Ralph > On Aug 5, 2023, at 12:47 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi Gary, > > On Fri, 4 Aug 2023 at 23:53, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> Great initiative Piotr! Thank you. One requirement I'd like to request is >> that this looks decent on mobile, which it does not ATM, at least on Chrome >> and Android 13. > > Yes, two mobile designs are available at the link I shared before: > > https://xd.adobe.com/view/455b5d92-d89b-45d9-984c-871974460249-1008/?fullscreen > > The Adobe presentation is fixed-width, but the finished website will > of course adapt to the width of the screen (up to a limit; I think > there are rules on the maximum amounts of words per line that allow > fast reading). > > Hi Ralph, > > On Sat, 5 Aug 2023 at 07:08, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> In general I like the direction of this. The site is much more colorful. >> However… >> 1. I really think we should have a separate web site for the log4j api. > > I agree. When we have an idea on the contents, I'll ask Daniel to > update his design. > >> 2. The manual needs much more than just being made pretty. > > I wish that weren't true. IIRC the idea we had with Christian and > Volkan, was to split manual and reference: > > * the reference would be automatically generated from the Javadoc > comments on component builders. It would provide crosslinks between > components, e.g. each appender could provide a list of the more > popular layouts and filters and a link to the whole list of them. > Since this will be automatically generated I thought we could generate > it based on a meta-data XML/JSON embedded in the JAR. This would also > serve as source for our configuration validation tool and could also > include third-party components that opt-in for it, > > * the manual would explain with examples how to use Log4j, without > being cluttered by the description of all our 400 components. > > Piotr
