> One more thought: Is adding Perl code to the conf file the
> right approach or should this be a perl API along the same lines
> as Eric's create_custom_level() which has to be called before
> init()?
Good question. I gave this some serious thought, and the only
guidelines I can think of that apply to the question are:
1) Partitioning: Highly interrelated parts of the problem should be in
the same piece of the system, i.e., things that belong together should
go together
2) Log4perl logging can be completely controlled from the config file,
without touching your application code
So since the user is using their custom conversion specifiers (cspecs)
in the config file, it would be handy to have them defined right next to
where they're using them.
This might suggest we should also offer a way to define custom *levels*
from the
config file, but there's a difference in that custom levels *are*
referenced from the code ($logger->litewarn(..)) while the use and
impact of custom cspec's are confined to the config file. But for
flexibility I'll include a method anyway.
So with all that in mind, I've implemented and checked in custom
cspec's, so you can do this in your config:
#'U' a global user-defined cspec
log4j.PatternLayout.cspec.U = sub { return "UID: $< "}
#'K' cspec local to appndr1 (pid in hex)
log4j.appender.appndr1.layout.cspec.K = sub { return sprintf "%1x", $$}
#and now you can use them
log4j.appender.appndr1.layout.ConversionPattern = %K %U %m%n
The benefit of this approach is that you can define and use the cspecs
right next to each other in the config file.
If you're an API kind of person, there's also this call:
Log::Log4perl::Layout::PatternLayout::
add_global_cspec('Z', sub {'zzzzzzzz'}); #snooze?
The appender-specific was implied by the config file syntax, so I
implemented both the global and the appender-specific ones.
Incompatability with log4j? This stuff possibly doesn't mesh with the
log4j proposal. But their proposal is just that, a proposal, which
might change anyway. It should be pretty obvious that perl code in a
conifg file isn't going to go anywhere with a java logger. If the log4j
people do implement something, our implementation is pretty much at the
surface, so it wouldn't be hard to rip out.
Security Issue: it occurred to me that some people might have a problem
with their config files all of a sudden becoming a place where perl code
gets eval'd and executed. If there's some installation where some group
of users has permission to edit the config file but shouldn't have
permission to run code then that might cause a problem. They can set
$Log::Log4perl::DONT_ALLOW_USER_DEFINED_CSPECS = 1;
before calling init(), which turns off the feature. I'm wondering if
this is good enough, should we default not allowing user-defined cspecs?
I've checked the code in, attached is a diff (may not work as a patch)
if you want to see what I've done.
Please let me know any comments or concerns.
--
Happy Trails. . .
Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA 94706
(510)525-5217 |
