|
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
|