If you create a file named log4j2.component.properties and place it in the class path you can specify any of the log4j system properties to tailor the desired behavior. The log4j-web module does this to disable the shutdown hook when running in a web container.
Ralph On Jun 5, 2014, at 11:42 AM, Matt Sicker <boa...@gmail.com> wrote: > 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> --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
