+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. >
