There is already one: JsonReader – a single-file JSON parser provided by JsonTemplateLayout.
On Thu, Feb 17, 2022 at 10:41 AM Jochen Wiedmann <[email protected]> wrote: > How about adopting a minimal Json parser into log4j-core? Examples: > > 1: https://github.com/KasparNagu/plain-java-json (ASL) > 2: https://code.google.com/archive/p/json-simple/ (ASL) > 3: https://github.com/ralfstx/minimal-json (MIT) > > Seems doable, and would work. > > Jochen > > On Thu, Feb 17, 2022 at 9:56 AM Volkan Yazıcı <[email protected]> wrote: > > > > +1 for supporting JSON as a built-in configuration format > > > > If we happen to move JsonReader to somewhere else, we shouldn't forget > > moving JsonReaderTest too. > > > > On Wed, Feb 16, 2022 at 7:32 PM Matt Sicker <[email protected]> wrote: > > > > > We've had some conversations about this off and on, though I don't > > > think we've had any formal decision or discussion on it. For Log4j > > > 3.x, we'd like to make it so that log4j-api, log4j-plugins, and > > > log4j-core only require the java.base module with optional > > > dependencies allowed for certain plumbing that can't otherwise be made > > > required (e.g., optional OSGi dependency to allow for participating in > > > bundle installation lifecycle events, optional LMAX Disruptor > > > dependency for asynchronous loggers, that sort of thing). > > > > > > With this idea, though, we lose support for all our configuration > > > factories except for the builder API and the properties format (which > > > uses said builder API) as XML is supported by the java.xml module > > > while JSON and YAML are supported by an optional Jackson dependency > > > for each. Many of us are unsatisfied with the properties configuration > > > format as it's difficult to represent properties as a tree of nodes > > > (as all the other configuration formats are tree-like), so this seems > > > like a poor user experience to leave as the default. > > > > > > One idea proposed was to support JSON as a built-in configuration > > > format. We have JSON parsing code present in JsonTemplateLayout which > > > can be moved to either log4j-core or even log4j-api to support at > > > least one basic structured format. If moved to the API, it can even be > > > used for the PropertiesUtil enhancements proposed for configuring > > > LoggerContext-specific options and other defaults. This JSON approach > > > is probably the lightest way we can handle it without introducing a > > > more complex parser. > > > > > > Any other ideas? Objections to doing something along these lines? The > > > JSON parsing can be moved to log4j-api, log4j-plugins, or log4j-core, > > > depending on how widely used the format will be here. > > > > > > > -- > Philosophy is useless, theology is worse. (Industrial Desease, Dire > Straits) >
