You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by James Bellenger <ja...@kixeye.com> on 2014/06/04 23:54:30 UTC
shutdownHook and programmatic configuration
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
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <bo...@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 <bo...@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 <bo...@gmail.com>
>>>
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: shutdownHook and programmatic configuration
Posted by Matt Sicker <bo...@gmail.com>.
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 <bo...@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 <bo...@gmail.com>
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: shutdownHook and programmatic configuration
Posted by James Bellenger <ja...@kixeye.com>.
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 <bo...@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 <bo...@gmail.com>
>
Re: shutdownHook and programmatic configuration
Posted by Matt Sicker <bo...@gmail.com>.
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 <bo...@gmail.com>
Re: shutdownHook and programmatic configuration
Posted by James Bellenger <ja...@kixeye.com>.
(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
>