Menu
▾
▴
log4perl-devel
|
From: <msc...@ao...> - 2003-03-15 05:32:41
|
Hi all, 0.30 is on the Log4perl home page now -- if it's OK, it'll move on to CPAN in a couple of days ... please give it a try! -- -- Mike ############################ # Mike Schilli # # log...@pe... # # http://perlmeister.com # # log4perl.sourceforge.net # ############################ |
|
From: Jim C. <jc...@di...> - 2003-04-17 23:13:33
Attachments:
logger.tgz
|
attached tarball has logger/*
Im proposing that it become part of the family - ie
gets a little piece of the namespace, since its so dependent
on the family resources.=20
so, without further ado, heres part of the pod.
NAME
Log::Log4perl::AutoCat - a simple Log4perl wrapper with
some cool features
DESCRIPTION
This is a wrapper class that uses the some of the really
cool Log::Log4perl features in corrupt an lazy ways;
AutoCategorization
normal use of Log4perl requires that you define a hierar=AD
chy of logging categories, and code them into your
classes. Because the logging category is orthogonal to
severity, and because your categories are essentially
unbounded, you can get detailed control over the logging
done by your application.
But (you knew this was coming), if youre lazy like me, you
dont want the drudgery of coming up with lots of cate=AD
gories, and making sure theyre consistent. You note that
your class hierarchy could serve as a logging category.
NOW IT CAN.
This package constructs such a $logcat dynamically, using
the package name, subroutine name, and line number. Sim=AD
plifying somewhat, the code does:
1. uses caller() to construct a category string dynamically.
2. fetches the $logger singleton {$logger =3D get_logger($logc=
at)}
3. tests if $logcat was a loggable event {$logger->is_$logcat(=
)}
4. record the invocation.
5. do the Log4perl call if 3 tests true
Step 4 is done just because its informative; all invoca=AD
tions are cataloged in %seenCat, and this can serve as a
good 1st estimate of test coverage of your application
code. This coverage is summarized at END time;
(15:24:24.772) Logger.END.info.106: $Seen Log Events: =3D [
{
'GenWidget.new.debug.34' =3D> 61,
'GenWidget.new.error.96' =3D> 5,
'GwApi.exit.error.328' =3D> 1,
'GwConf.read_file.info.137' =3D> 12,
'Logger.END.info.106' =3D> 1,
'Widget.Match.debug.225' =3D> 61,
'Widget.Match.debug.240' =3D> 61,
'Widget.Match.debug.257' =3D> 1,
'Widget.Match.debug.263' =3D> 543,
'Widget.Match.debug.272' =3D> 55,
'Widget.Match.error.280' =3D> 5,
'Widget.import.info.85' =3D> 1,
'Widget.loadWidgets.debug.118' =3D> 13,
'Widget.loadWidgets.debug.120' =3D> 1,
'TestWidget.crosscheck.info.254' =3D> 1,
'TestWidget.crosscheck.info.267' =3D> 231,
'TestWidget.init.info.42' =3D> 1,
'TestWidget.init.info.67' =3D> 1,
'TestWidget.init.info.68' =3D> 1,
'TestWidget.new_from_xml.debug.128' =3D> 11,
'TestWidget.new_from_xml.debug.143' =3D> 12,
'TestWidget.new_from_xml.debug.165' =3D> 46,
'TestWidget.new_from_xml.debug.197' =3D> 46,
'TestWidget.new_from_xml.error.198' =3D> 3,
'TestWidget.new_from_xml.info.127' =3D> 11,
'TestWidget.new_from_xml.info.173' =3D> 231
} ];
Configuration
Given that categories are built on the fly, and that cate=AD
gories are reported at application END, you can take the
reported categories and roll them back into the log4perl
config-file.
Other Features
Configuration Loading
If use Log::Log4perl::AutoCat is given an import list
which includes initstr =3D> q{}, or initfile =3D> $filename,
the string or file is used to initialize Log::Log4perl.
These are simple import-wrappers on existing Log4perl ini=AD
tialization techniques. Since this is my 1st project to
use Log::Log4perl, I dont have the experience to know why
they are not already exposed in Log::Log4perl::import().
Perhaps reasons for not doing so will become apparent as a
result of this experimental feature.
Aliasing
If use Log::Log4perl::AutoCat is given an import list
which includes alias =3D> $aliasname, Log::Log4perl::Auto=AD
Cat::AUTOLOAD is aliased into package $aliasname. This
shorthand is convenient for using class method invocation
of the Logger, and is necessary for correct functioning of
the features described next.
Note: because aliasing is used in optimization phase, it
must be imported via use, it cannot be deferred as in
require, import.
untar and read on..
feedback and patches welcome..
jimc
|
|
From: Mike S. <msc...@ao...> - 2003-04-22 00:22:25
|
jc...@di... wrote: > But (you knew this was coming), if youre lazy like me, you > dont want the drudgery of coming up with lots of cate=AD > gories, and making sure theyre consistent. You note that > your class hierarchy could serve as a logging category. > NOW IT CAN.=20 Thanks for your post -- sorry it took so long to respond. Couple of point= s: * Seems like parts of what your implementation provides are already=20 available in Log::Log4perl, namely the "stealth loggers" feature. I'm=20 almost sure you've read these two docs, just in case: http://log4perl.sourceforge.net/releases/Log-Log4perl/docs/html/Log/Log4p= erl/FAQ.html#what's_the_easiest_way_to_use_log4perl http://log4perl.sourceforge.net/releases/Log-Log4perl/docs/html/Log/Log4p= erl.html#stealth_loggers It autocategorizes all loggers based on the class a particular logger is=20 in, but at compile time and not at runtime. * What your implementation provides on top of that, is the=20 categorization based on function names and line numbers. I think the=20 first one is a useful feature. The 2nd one I find somewhat doubtful,=20 because line numbers change quickly as a program evolves and it's=20 probably better to control messages with "message filters" if you need=20 to be able to intervene at such a low level. * I also find the "coverage" feature very useful, we should probably=20 have that in Log::Log4perl. > These are simple import-wrappers on existing Log4perl initialization > techniques. Since this is my 1st project to use Log::Log4perl, I dont > have the experience to know why they are not already exposed in > Log::Log4perl::import(). Perhaps reasons for not doing so will become > apparent as a result of this experimental feature. Not sure what you're referring to here. The stealth logger docs mention=20 ways to simplify the init (like easy_init({file =3D> ..}). Let me know=20 what you mean exactly if I missed anything. All in all, in looks interesting and I'd certainly be interested in a=20 complete distro to install and play with -- are you planning on=20 providing that? --=20 -- Mike Mike Schilli log...@pe... |
|
From: Jim C. <jc...@di...> - 2003-04-22 06:29:51
|
Mike Schilli wrote:
> jc...@di... wrote:
>
>> But (you knew this was coming), if youre lazy like me, you
>> dont want the drudgery of coming up with lots of cate=AD
>> gories, and making sure theyre consistent. You note that
>> your class hierarchy could serve as a logging category.
>> NOW IT CAN.=20
>
>
> Thanks for your post -- sorry it took so long to respond. Couple of=20
> points:
>
> * Seems like parts of what your implementation provides are already=20
> available in Log::Log4perl, namely the "stealth loggers" feature. I'm=20
> almost sure you've read these two docs, just in case:
I did, but not carefully/critically enough. I didnt like the functions=20
being imported into
the calling package, in part cuz I was re-implementing an old logger. =20
My January version
was that adaptor class to Log::Log4perl. It also appeared in my cursory=20
review that :easy
also didnt give me a whole lot of control w/o embedding the config in=20
the code.
> * What your implementation provides on top of that, is the=20
> categorization based on function names and line numbers. I think the=20
> first one is a useful feature. The 2nd one I find somewhat doubtful,=20
> because line numbers change quickly as a program evolves and it's=20
> probably better to control messages with "message filters" if you need=20
> to be able to intervene at such a low level.
Line numbers indeed change during development, but the filtering works=20
hierarchically,
including on function names and logging level, so line-number churn is=20
less critical than
it otherwize would be.=20
Line numbers also settle down, and part of the value of the "log a lot=20
and filter"
strategy is that you can enable logging to support debugging long after=20
the module
is 'stable', and in production. Line numbers just give an extra level=20
of control if
you want to use it.
I actually thought of removing the line-numbers at one point, but the=20
'coverage' feature
accentuated its value, and theres no downside (assuming that subroutine=20
name was an
essential enhancement)
Lastly, when I did the 1st wrapping, filters didnt exist. Now that it=20
does, I will get around
to looking at it for ideas.
>
> * I also find the "coverage" feature very useful, we should probably=20
> have that in Log::Log4perl.
:-). The depth of coverage is significantly enhanced by subroutine &=20
line-number. Ive often
wished for a __SUB__ analogue to __PACKAGE__, had it been available, Id=20
never have gone
the AUTOLOAD { caller(1) } route.
>
>> These are simple import-wrappers on existing Log4perl initialization
>> techniques. Since this is my 1st project to use Log::Log4perl, I dont
>> have the experience to know why they are not already exposed in
>> Log::Log4perl::import(). Perhaps reasons for not doing so will become
>> apparent as a result of this experimental feature.
>
>
> Not sure what you're referring to here. The stealth logger docs=20
> mention ways to simplify the init (like easy_init({file =3D> ..}). Let=20
> me know what you mean exactly if I missed anything.
The only new thing here is exposure via sub import(), which makes it=20
possible load an
initialization file at compile-time. This is 'necessary' cuz=20
optimizer.pm operates
at use-time. It can be done in a BEGIN block, but thats easy to=20
overlook, and a use-arg
just felt cool. I believe that anything else (ie: INIT or CHECK?) is=20
too late.
I was asking why you didnt expose the initialization stuff via import(),
and/or whether you might consider doing so.
>
> All in all, in looks interesting and I'd certainly be interested in a=20
> complete distro to install and play with -- are you planning on=20
> providing that?
>
I'll work one up. I wanted to grab Log::Log4perl::AutoCategorize (or=20
similar)
for my namespace, and get the (alias =3D> Logger) import working. For=20
this, I need
your endorsement (ie, I cant take what you dont want to give).
Even if this doesnt eventually earn that name, look at optimizer, its=20
damn cool.
thanks
jimc
|
|
From: Mike S. <msc...@ao...> - 2003-04-23 18:01:24
|
jc...@di... wrote: > I'll work one up. I wanted to grab Log::Log4perl::AutoCategorize (or > similar) > for my namespace, and get the (alias => Logger) import working. For > this, I need > your endorsement (ie, I cant take what you dont want to give). Excellent. Once you've got something like a beta, we can reconvene and decide. -- -- Mike Mike Schilli m...@pe... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X