my usual retrieval of the logging instance is

my $logger = get_logger((caller(0))[3]);

so my log entries usually look like

2006/03/02 14::55::53 DataMatrix.Encoders.asciiEncoder - DEBUG - data is 99ABC00

Pattern in log.conf for the layout for me is usually
%d %c - %p - %m%n
or datetime category - level - message newline

Creating the category this way means the category is the fully qualified name of the current function/method. I usually dont include the line numbe, because it just makes the log line longer, and my functions/methods are usually between 5-20 lines

This means I can activate the logger in a single function in a package with the following config line

log4perl.logger.path.to.package.function=DEBUG,CONSOLE
[download]

I can activate every logger in a package with

log4perl.logger.path.to.package=DEBUG,CONSOLE
[download]

And I can activate the logging in the entire application with

log4perl.logger=DEBUG,CONSOLE
[download]

I can even activate a highly specific logger deep in a function this way

sub complexFunction {
  my (%args) = @_;
  ...
  # deep inside some complex code
  { # create a new scope
    my $logger - get_logger((caller(0))[3] . "::complexBit");
    ...
    $logger->debug("enzyme experiencing toxic reation...");
    ...
  } # close scope, leaving that logger behind
[download]

Match that with a config file directive like this

log4perl.logger.path.to.package.function.complexBit=DEBUG,COMLPEXFILE
[download]

and you can comment out this line to not see this logging, or uncomment to activate it. This technique is especially powerful if the deep logger is inside several loops, and its quite voluminous.

If you start the application with that line in the log config commented out, you wont see anything. If your initialisation of Log4 perl is by using

Log::Log4perl->init_and_watch('path/to/config', $delay);
[download]

then you can start the app, and uncomment the line, wait $delay seconds for the logging to start, comment out the line again and wait upto $delay seconds for it to stop again. Or you could setup a signal handler to toggle the activation of a logging category in response to you sending a SIGUSR1 to the applications process - we've used this technique when debugging DBI SQL problems. Application normally has quiencent logging, but we can activate logging for a single running instance of that application by sending it a signal. Better than all the logging starting for your running processes that share a config file!