Re: shutdownHook and programmatic configuration
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
Re: shutdownHook and programmatic configuration
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
Re: shutdownHook and programmatic configuration
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
Re: shutdownHook and programmatic configuration
(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
Re: shutdownHook and programmatic configuration
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
