That doesn't sound too far off from what I'd expect is the case (or desired case) in a lot of environments. You can use property placeholders in a lot of places to be later configured through various means, and you can even specify the configuration via JNDI.
In regards to the shutdown hook, perhaps it would be better to offer a public API to shutdown instead? That way each use case can hook it into the proper location. On 5 June 2014 01:17, James Bellenger <ja...@kixeye.com> wrote: > 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> > > > -- Matt Sicker <boa...@gmail.com>
