OK, things could get complicated for a full feature list. For now, I have a use case where setting levels in a running system is important, so making that easy is nice.
Gary On Sat, Aug 8, 2015 at 12:19 PM, Ralph Goers <[email protected]> wrote: > 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] > > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
