Menu
▾
▴
Re: [log4perl-devel] Log::Log4perl::AutoCategorize
|
From: Jim C. <jc...@di...> - 2003-06-02 15:58:43
|
Mike Schilli wrote:
>On Fri, 30 May 2003, Jim Cromie wrote:
>
>
>
>>Yeah, the optimizer part took some time to Grok.
>>I hope that the code and the comments will take you thru the hard parts,
>>let me know if otherwize.
>>
>>
>
>Jim, nice work! Here's a couple of item I stumbled across, in the order
>I encountered them:
>
:-D
thx Mike & Kevin. Yours are the 1st other set of eyeballs on it.
Did you get a chance to run 'make test' ?
On what platform(s) ?
Did it just work ?
Did you run perftests/timeit.sh ? (can you send me results ?)
>* You might want to explain what 'static method style' is.
>
>
heh - static method is what I called it for lack of a better description.
'static method' is equivalent (at an approximate level) to 'class method';
ie: Class->method() # what Ive called static (probably needs
better name)
vs: $obj->method() # std instance method
vs: Class::Method() # Fully Qualified, class method.
I dont think there is a preferred name for this construct, would welcome
corrections or
pod-citations, or even opinions as to what best conveys that the best.
>* You write: "Log::Log4perl provides easy_init(), which achieves some
> simplification of categories, but you are still faced with creating
> them once" -- but this function doesn't really do anything for categories.
> The stealth logger feature included via 'use Log::Log4perl qw(:easy);'
> is probably what you're referring to -- although you don't have to
> 'create' categories, it just uses the class names.
>
>
heh - I guess I should write a use-case of it, following the specific
example in perftest/t2.pl.
Then with a few tips, I could re-write it for a fair comparison wrt
style, performance, etc..
>* As mentioned before, I like the coverage feature a lot. What's the
> "unseen log", though, and how does it work?
>
>
When function name munging is done (at use/check time), each munged name
is recorded
as a key in an %unseen hash. As each function-name is 1st seen by
AUTOLOAD,
and vivified into a subroutine, the name is deleted from %unseen.
What remains at
end-time are munged function names that were never called, so were never
seen by AUTOLOAD.
>* Looks like in
> # for example, debug Frob.pm, but only info on Frob::nicate()
> log4perl.category.Frob = DEBUG
> log4perl.category.Frob.nicate.debug = INFO
> -- there's no appender, would be informative to see what the recommended
> way of defining them is (and think of messages "bubbling up" :).
>
>
hmm. I left out any appender precisely to focus on how successive
layers of categories would
filter the items - most debug from Frob:: would logged, but not from
nicate(), cuz of the
more specific config-item. And so on. Ill try to clarify it, and
re-test the phrasing on you all.
>* I didn't understand what you meant by this: "Its probably a bit
> confusing at 1st to have debug=INFO, but this is intentional; it tells
> you the logging level thats coded (so you dont have to go back to the
> source everytime), and therefore what is done if the config-line is
> commented out."
>
>
self-fullfilling prophesy on the confusion, eh ?
The category that AUTOLOAD constructs includes the logging-level as
extracted from the function,
(ex: info from Logger->info_00013). Because its part of the category,
it ends up in the coverage logs,
and can be cut-pasted into the config-file, where it serves to convey
both; 'this is what it does now',
and 'this is what it does by default'.
The 'does now' part is debug=INFO (ie this debug message is suppressed,
cuz INFO is higher than debug)
The 'default' part is as follows : the code contains a debug call at
package X, method Y, line Z, and if you
were to comment out this config-line, it would bubble up, and be dealt
with according to other
config items.
>* Question: If a module author decides to ship his module with
> Log::Log4perl::AutoCategorize, will it work if the main program
> (1) doesn't use it?
> (2) uses plain Log::Log4perl?
>
>
REALLY good question, cuz its really important to coexist, and I hadnt
thought to test for it.
For 1, Id expect it would just pick up the default config.
For 2, I suspect that Imight load right over existing config, which
would be bad.
which brings me to a set of Qs;
1 .Are you currently considering an include mechanism so that
a config could be broken down into chunks that control the app's
subsystems ?
2. Would the include scheme work for overrides & subclasses ?
Id like it to be possible to specify both an initfile => $file, and
initstr => q{blah ..},
and have the initfile specify the general logging behavior (for say
a set of related utilities)
with specific overrides given for utility-A, B, etc.
3. wrt init_and_watch(), I need a notification when a new config is
loaded and parsed.
(its probably there already - I havent looked yet) I need to
undefine munged-functions
where the config has changed, so AUTOLOAD is called again for each
item, and can rewrite
the corresponding a-sub according to the new config.
Id prefer not to undefine all subs, but this means that the
notification would have to include
a list of categories that were changed ( added/deleted/altered -
tho I dont need to know which)
4. th down, punt.
The issue boils down to; what happens if Log::Log4perl->init() is
called 2x.
In your (2) scenario it seems quite likely to happen, but could also
happen while using
just Log::Log4perl, wo my wrapper.
I currently rely on the over-load; I load my default-config at
use-time, unless either initfile or
initstr is given. Since my default-load happens at use time, if the
application calls init() itself,
it will most likely override my config.
>* As for shipping it with Log::Log4perl ... you're depending on optimizer.pm
> which depends on 5.7.2 -- and Log::Log4perl works with 5.005_03. I
> think you're gonna be better off shipping it as a separate module to
> CPAN, this way you're free in what modules you depend on and don't
> have to support odd configurations (perl 5.005_03, Windows). We'll
> certainly provide a plug for Log::Log4perl::AutoCategorize within the
> Log::Log4perl docs.
>
>
:-D
heh, from the outset I had a very different interface, (ie
Logger->debug()), and dependencies
on new modules, so I had the separate dist as a mind-set. I never even
got around to thinking
about versions support.
Ill start a thread on modules-*@perl.org now..
If you had an opportunity to change the package-name (you do), would you ?
Log::Log4perl::AutoCat (shorter, but ultimately not as descriptive)
Log::Log4perl::AutoCover (emphasize coverage features)
any other possibilities ??
-- Mike
>Mike Schilli
>log...@pe...
>http://perlmeister.com
>http://log4perl.sourceforge.net
>
>
>
-jimc
|
