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)
