Hi Matt. Our environment is a custom scala application server. Our use case is the same as most standalone java apps -- we just want to log stuff and have it go somewhere. We're extremely vanilla in what we need from log4j -- it's really just different combinations of console, rollingfile, and flume appenders.
Rationale for some of our requirements, are in priority order: *having shutdownHook disabled* Our server registers its own jvm shutdown hook to know when to start shutting itself down. Shutdown isn't always straight forward, so we need log4j to keep running to capture logs. *programmatic log4j configuration* This is more of a proxy requirement -- the real need is to be able to support both local and deployed environments without having repetition in our logging configuration. We do this by having one file define global things like log levels for different packages, and then multiple config files for each supported appender. At runtime, we configure the root logger with the global configuration, and then load config files for each appender we need and attach it to the root logger. *not depending on log4j.configurationFile* More of an aesthetic reason than anything else. We're already have a lot of code and log4j meta configuration going on, and the more ways we can simplify that the better. Why depend on two ways of configuring log4j when we might get away with just one? Overall, our programmatic configuration approach has felt pretty far off the typical configuration path, and tends to break in frequent and subtle ways. Is it atypical to want DRY logging configurations? How do other people approach this? On Wed, Jun 4, 2014 at 10:32 PM, Matt Sicker <boa...@gmail.com> wrote: > It's supposed to help clean up any resources and commit anything necessary. > It sounds like you're having the opposite effect, though. Any details about > environment or plugins that might help? > > > On 4 June 2014 16:59, James Bellenger <ja...@kixeye.com> wrote: > > > (sorry for the fat-fingered send earlier) > > > > Hello. > > Our environment depends on these things: > > > > - programmatic log4j configuration > > - having "shutdownHook" disabled > > - ideally: not having to depend on the log4j.configurationFile > > environment var > > > > I've had a hard time balancing all three of them. > > Generally, the first access on the rootLogger context installs a default > > configuration that always enables the shutdownHook, and there's not a > clear > > means to disable it without falling back to the log4j.configurationFile > > property. Some of the methods available for reconfiguration (onChange, > > setConfiguration), don't reset the shutdown hook. > > > > As a new user to the group, and out of curiosity, why does shutdownHook > > exist in the first place? It causes us to lose logs when the system is > > shutting down -- why is this on by default? > > > > > > On Wed, Jun 4, 2014 at 2:54 PM, James Bellenger <ja...@kixeye.com> > wrote: > > > > > Hello. > > > Our environment depends on two things: > > > > > > - programmatic log4j configuration > > > - having "shutdownHook" disabled > > > - ideally: not having to depend on the log4j.configurationFile > > > environment var > > > > > > programmatic configuration of log4j2. > > > In trying to remove any dependencies on the log4j.configurationFile env > > > variable, I've found that there's not a good way to ensure that there > is > > > > > > > > > -- > Matt Sicker <boa...@gmail.com> >
