Sorry if it appears we don’t care, but your original message seemed to be full of sarcasm and didn’t ask for any real help.
FWIW, the goal wasn’t to make configuration harder - it was to make configuration changes thread safe. Log4j 1 has thread safety issues and locks in ways that can cause deadlocks. Some of the things that you consider to be part of the Log4j 1 API are really part of the internals of the system. Like any other software I am sure our documentation can be improved. If you compare the amount of documentation available for Log4j 2 against what was available for Log4j 1 I think we are miles ahead. If you find places that it can be improved please open a Jira issue and possibly even supply a patch. But the manual is correct in that the safest way to perform programmatic configuration is to implement a custom ConfigurationFactory. I just recently added a sample to the log4j-samples/configuration project. That hasn’t been released yet but you can check it out from git. Some things, like adding a new LoggerConfig, cannot be done safely to the current configuration, and so the only way to do that is to create a new Configuration. Of course that isn’t as simple as it was with Log4j 1, but it also avoids a whole pile of threading issues. Ralph > On Aug 8, 2015, at 9:51 AM, Xen <[email protected]> wrote: > > Heh, it seems more like you went out of your way to close off a configuration > method on purpose that you would know would still be in high demand by a lot > of people. > > The choice to have only configuration per external file would definitely have > raised a lot of eyebrows. And I bet, still does with anyone who reads that > piece of the manual. > > Quoted for truth ;-): > > ==== > Configuration of Log4j 2 can be accomplished in 1 of 4 ways: > 1. Through a configuration file written in XML, JSON, or YAML. > 2. Programmatically, by creating a ConfigurationFactory and Configuration > implementation. > 3. Programmatically, by calling the APIs exposed in the Configuration > interface to add components > to the default configuration. > 4. Programmatically, by calling methods on the internal Logger class. > > (...) > > Note that unlike Log4j 1.x, the public Log4j 2 API does not expose methods to > add, modify or remove appenders and filters or manipulate the configuration > in any way. > ==== > > The manual basically hides any form of information relevant to or pertinent > with manual configuration. The information is almost nowhere to be found? > > What the manual does indicate about manual configuration is not trivial: > > "Modifying the way in which logging can be configured is usually one of the > areas with the most interest. The primary method for doing that is by > implementing or extending a ConfigurationFactory. Log4j provides two ways of > adding new ConfigurationFactories. The first is by defining the system > property named "log4j.configurationFactory" to the name of the class that > should be searched first for a configuration. The second method is by > defining the ConfigurationFactory as a Plugin." > > Should a method for programmatic configuration exist and be usable/reachable, > supported and documented, many users would surely use it or prefer it or make > use of it. > > So I don't think you've gone out of your way to please everyone ;-). I think > you made the rational choice to displease a lot of people. There must be > thousands of people who'd give preference to programmatic configuration when > given the choice. That's just the reality of it. > > I'm sorry but uhm yeah. I still think I need to use Log4j 2 but I'll go about > experimenting with its configuration in the coming days. > > Thanks you for your help in any case :). > > See ya :). > > X. > > > Quoting Ralph Goers <[email protected]>: > >> I guess you can't please everybody. >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
