[log4perl-devel] Re: RFC - Logger wrapper on Log::Log4perl

[Jim C. <jc...@di...>]

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