I have to amend what I said. In reviewing the pdf documentation I do see that we support dynamically adding a LoggerConfig to an existing configuration.
Gary, while we could also add methods to make this simpler, doing that would almost certainly require some sort of “begin” and “end” as you might want to add an existing appender as a reference to a LoggerConfig, or create a new Appender and then add that to a LoggerConfig, or add a Filter, etc, before updateLoggers is called. Ralph > On Aug 8, 2015, at 11:26 AM, Ralph Goers <[email protected]> wrote: > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
