that was the idea, but now i see that's not going to work. originally i
just wanted to change the log level on the root logger, which actually did
persist (i was dumb and spaced the fact that i was bypassing the embedded
perl engine when i was testing), but that only affected the one
interpreter instance and there are many sitting in a shared pool, so that
doesn't really help my needs.
it seems at this point, my best approach would be to figure out a way to
have the configuration be external and then use the 'init_and_watch()'
approach, sending a HUP to cause the configuration to be re-read.
--
-jae
On 4/18/12 11:29 AM, "Mike Schilli" <m...@perlmeister.com> wrote:
>On Wed, 18 Apr 2012, Gangemi, Jae wrote:
>
>> actually, no - the call into the system could be considered the
>> equivalent of running a cgi script inside of mod_perl, there is no
>>signal
>> handler involved, but i now realize my original approach just isn't
>>going
>> to work.
>
>I see, and the reset to the old configuration is related to something
>within the system calling Log4perl's init()?
>
>--
>-- Mike
>
>Mike Schilli
>m...@perlmeister.com
>
>> the reason i'm not using 'init_and_watch()' is b/c we embed the
>> configuration file inside the code base (which is contained in a custom,
>> encrypted archive) and 'init_and_watch' only works w/ an external file,
>> but in order to make this work, i think i'm going to have to use some
>>kind
>> of external configuration file or change how 'init_and_watch' works
>> locally.
>>
>> thanks!
>>
>> --
>> -jae
>>
>>
>>
>>
>> On 4/17/12 9:46 PM, "Mike Schilli" <m...@perlmeister.com> wrote:
>>
>>> On Tue, 17 Apr 2012, Gangemi, Jae wrote:
>>>
>>>> am i missing something w/ this idea or will i need to re-initialize
>>>> log4perl w/ a new configuration in order to make this work?
>>>
>>> You're not saying how your call into the system works, I presume that
>>> you're using a signal handler or some such to run a function that
>>> manipulates the logger on a received signal. Then, somehow Log4perl
>>>gets
>>> reinitialized by calling init() and it's back to normal. With mod_perl,
>>> this happens e.g. when Apache starts a new child process, I suspect
>>> something similar is happening in your embedded system.
>>>
>>> I wonder why you're not simply using init_and_watch() and modify the
>>> external config file to regularly check and reload it?
>>>
>>> --
>>> -- Mike
>>>
>>> Mike Schilli
>>> m...@perlmeister.com
>>>
>>>> hello -
>>>>
>>>> i'm currently running log4perl inside an embedded instance, for all
>>>> intents and purposes, you could say it's an environment similar to
>>>> mod_perl.
>>>>
>>>> while the system is running, i would like to send a command that
>>>> changes
>>>> the log level of either the root logger or against one of the logger
>>>> categories (and potentially dynamically adding an appender so i can
>>>>log
>>>> to
>>>> a separate file.
>>>>
>>>> the problem i am having the log level does not persist between calls
>>>> into the system. i can make a call in and change the log level (and
>>>>log
>>>> a
>>>> message at the new level to make sure it worked) but on a subsequent
>>>> call,
>>>> the log level has been reset to what log4perl was originally
>>>>initialized
>>>> with, i.e.:
>>>>
>>>> $logger = Log::Log4perl->get_logger("");
>>>>
>>>> $logger->fatal("fatal message");
>>>> $logger->trace("trace message, should not see");
>>>>
>>>> $logger->level($TRACE);
>>>> $logger->level("trace message, should see");
>>>>
>>
>>
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
log4perl-devel mailing list
log4perl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/log4perl-devel
