1. There are examples that show how to modify the configuration programmatically. I recently created an example that is checked into the log4j-samples subproject. However, it is probably more complicated than what you are asking for. 2. Log4j 1 intermixed the public API that applications used to perform logging with what were really internal classes - it was not really possible to tell the difference. With Log4j 2 you have assurances that we will do our utmost to preserve compatibility of the API - and it is clearly defined what that is. Modifying the configuration aspects of logging, while common, delve into the details of the implementation of the logging framework. While we will always try to preserve compatibility - especially on the classes we know users interact with - we won’t guarantee that interfaces or implementations won’t be changed. However, for the use cases of modifying logging levels, or modifying the configuration in “normal” ways you should consider that those things may be done safely with minimal risk that they will break with a new release.
We probably could use better documentation on what we guarantee with backward compatibility and what we don’t. To achieve what you want just get the LoggerConfig you want to modify, change its level and then call the updateLoggers() method of the LoggerContext. Ralph > On Aug 6, 2015, at 1:44 PM, Xen <[email protected]> wrote: > > Hey, > > I just read the manual at > https://logging.apache.org/log4j/2.0/log4j-users-guide.pdf. A reasonably good > manual I must say, compared to some products out there. > > It doesn't really mention the public API though, only sparsely throughout the > examples. I skipped through the remainder of the property sections for all > the things. > > ;-). > > I am led to believe that I am not meant to configure log4j2 during program > execution. Nor can I change the configuration except by loading different > configuration files. > > I am happy to assume that this is rather odd. I would like it if I had a main > configuration file indeed, but... > > My application needs to adjust logging levels on the fly. That would be the > levels indicated by LoggerConfig objects. > > It would not suffice, really, to have several config files, each for each > wanted state. > > Should I use log4j version one? > > It seems to be the better choice as the way you keep mentioning it (or the > site/manual mentions it) but I am hesitant always to use older versions. > > I just want my application to be able to e.g. enter a debugging mode by > itself. This would require for instance the levels of certain LoggerConfigs > to be raised or lowered. You might want to enter a verbose mode where a > certain low level component starts outputting data. > > Particularly in response to the console, but I might even remotely monitor my > application using a custom shell. > > I am glad that in any case there is a default separation of test and main > scripts, because logging may interfere with unit tests. > > But I don't really like this static configuration. I was expecting log4j2 to > be really good, but then it says that 3 of the 4 configuration options are > not available, and the FAQ summarily states that if you work around it, your > code might break with every minor revision. Great. Yikes. > > That's not a real good way of having a public API ;-). And I can't go and > extend it when I'm just a new user. > > What is the solution for me here? I just want to go to a LoggerConfig and > change its level. Ideally I would have different states (that could of course > be represented by config files) that I would load all in one go (as in, a > complete state describing multiple configurations of different components, > belonging together). But I also want to be able to manually set and remove > (change) individual components. > > Such would be accomplished by simply changing the level of one LoggerConfig. > Is it not possible? > > Regards, > > Bart. > > > --------------------------------------------------------------------- > 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]
