Menu
▾
▴
log4perl-devel
|
From: Mike S. <msc...@ao...> - 2003-02-19 19:38:49
|
Pet...@Dr... wrote:
> I prefer to define constants for the return values (and put
> all constants in a common class Log::Log4per::Constants).
> A filter may return
>
> Log::Log4perl::Constants::OK
> Log::Log4perl::Constants::DECLINED
>
> The constants may be imported by default so that you can write
>
> log4perl.filter.MyFilter = sub { \
> my %p = @_; \
> (%p{log4p_level} == WARN) ? OK : DECLINED; \
>
Nice. Definitely the correct way of defining it and being flexible to
add stuff in the future. On the other hand, I really like constructs like
sub { /x/ and /y/ }
which gets really hairy/lengthy with constants.
> 2. Can we have a sub here as well? Maybe I want to make my
> logic dependent on localtime() or the moon phases or have a
> switch() on hostnames to have development and production
> logic in one config file or...
>
You can do that in two different ways: Define the "advanced" logic in
the filters used by the Bool filter (which I think I would prefer) but,
since yesterday, the "logic" field in the Bool filter just gets "eval"ed
as regular Perl code, so you can put in there whatever you like. The
latest version from CVS sports almost everything already, please check
it out!
> 3. What a about message redirection? Are there plans for the
> future that a filter (or whatever) can forward a message to
> another appender?
>
Interesting feature, I haven't thought of that yet (neither have the
log4j folks). I gotta think about that. Can you imagine a use case?
Also, we could implement that either as a Log4perl-centric feature based
on filter return code (as you suggested) or as a function/method call
inside the filter (redir_to_appender(blah)).
--
-- Mike
Mike Schilli
log...@pe...
|
|
From: <Msc...@ao...> - 2003-02-23 22:16:37
|
In a message dated 2/22/03 9:05:04 AM Pacific Standard Time, ke...@go...
writes:
> Some observations:
Kevin, you've made some excellent points, see details inline ...
> 1) Regarding log4j compatibility, if someone implements log4j-style
> filters it's just a matter of specifying a different implementation
> class in the config, right? Hmm, except for the chaining thing, and
> that log4j filters return ACCEPT/DENY/NEUTRAL instead of true/false.
The Log4j folks don't have a notion of defining filters in the Property-style
config files, and probably won't have one in the forseeable future, so we're
exploring unchartered waters. No matter how we're implementing it, it'll
always be incompatible with Log4j. But, you're right, maybe some day we'll
need a notion of a "chained" filter set. It can be accomplished by employing
a strategy similar to the "Bool"ean filter: A "Chained" filter, taking a
chain of filters. And the chain defines what it means (block/neutral/accept)
if filter X returns true or false (note that the chain can base its decision
on the same parameters as the filter has available, because the chain calls
the filter in turn).
The current design is simple: An appender has only one filter attached
(returning true or false), but it's up to this filter to be smart and use the
services of other filters in creative ways.
>
> Is there any way to differentiate? Is it worth calling our filters
> "pfilters" or "bfilter" (b for boolean)?
We can make the distinction at the filter level, see above.
> 2) As I was writing those examples, I wondered if it's worthwhile
> setting up to allow defining a filter per-appender as well as global,
> like we do for the cspec's? (see t/033UsrCspec.t). Then you can use
> them close to where they're defined.
Interesting thought. With cspecs, I can clearly see the importance: You've
got a very limited namespace (one-letter words) and local settings could
pollute the global namespace quickly if they weren't separated.
However, the filter case is different, their namespace is virtually
unlimited. Kind of like loggers reference appenders -- there's no localized
namespace. And it's OK to define them close to where they're used:
# Error appender
log4perl.appender.AppError = Log::Dispatch::File
log4perl.appender.AppError.filename = /tmp/app.err
log4perl.appender.AppError.layout = SimpleLayout
log4perl.filter.MatchError =
Log::Log4perl::Filter::LevelMatch
log4perl.filter.MatchError.LevelToMatch = WARN
log4perl.appender.AppError.Filter = MatchError
What we could do, though (without too much effort, I hope) is shorten the
definition by cutting out the filter name:
# Error appender
log4perl.appender.AppError = Log::Dispatch::File
log4perl.appender.AppError.filename = /tmp/app.err
log4perl.appender.AppError.layout = SimpleLayout
log4perl.appender.AppError.Filter =
Log::Log4perl::Filter::LevelMatch
log4perl.appender.AppError.Filter.LevelToMatch = WARN
This way, there's no name pollution -- but on the other hand you're limited
because filters like Bool(ean) expect named filters.
> 3) There seems to be a typo in the email, under "Attaching a filter to
> an appender" it says
> log4perl.appender.MyAppender = MyFilter
> s/b
> log4perl.appender.MyAppender.Filter = MyFilter
> right?
Good catch! Fixed in the docs now.
>
> 4) Tiny point: do you really want to call it Bool.pm instead of
> Boolean.pm? What's a Bool?
The name of the guy who invented it was "George Boole", so "Bool" doesn't
make any sense, you're right :). I'll change it to Boolean (hope not too many
people have read this week's recipe :). If you have, use "Boolean.pm" from
now on! :)
>
> 5) Why is "f" capitalized in "log4perl.appender.Screen.Filter" but not
> in "log4perl.filter.Match1"? (I'm as guilty as anyone of inconistency
> here, but it's never to late to reform!)
Good point. It's "log4perl.filter" because it's "log4perl.appender". All
that's lower-cased, by log4j standards. On the other hand, the situation with
appender or other properties/attributes is less clear: Seems like they're
uppercase if they're local to the current object and lowercase if they're
property "keywords" (compare log4j.appender.X.threshold vs.
log4j.appender.X.File). In log4perl, we haven't made that distinction so far,
properties are typically lowercase for the perl appenders (Java appenders
conform to log4j, though) -- mainly because Log::Dispatch has lowercase
attributes. I was just concerned about an appender in the Log::Dispatch
hierarchy accidently defining a "filter" attribute. If our "Filter" keyword
is uppercase, it's less likely to clash (although still ambiguous), although,
you're right about it being inconsistent.
>
> 6) log4j's decide() method returns a constant ACCEPT/DENY/NEUTRAL, but
> our decide() returns a boolean. Wouldn't it be better to name our
> method let_pass() or is_loggable() or something that implies how the
> boolean will be treated? ("Hmm, I can't remember, does decide()==true
> mean decides to filter it out, or decides to log it?"). I think a hint
> to the developer might be appreciated some day.
Yep, makes sense. I'll put on my thinking cap ... :)
Thanks for the feedback, changes are checked in (BTW in case I haven't
mentioned it, it's all implemented/documented already, check t/040Filter.t
for more or less typical use cases).
-- Mike
Mike Schilli
log...@pe...
|
|
From: Dintelmann, P. <Pet...@Dr...> - 2003-02-24 08:07:33
|
> Mike Schilli wrote:
> > Pet...@Dr... wrote:
> >
> > > I prefer to define constants for the return values (and put
> > >
> > Nice. Definitely the correct way of defining it and being
> flexible to
> > add stuff in the future. On the other hand, I really like
> constructs like
> >
> > sub { /x/ and /y/ }
>
> I agree with Mike on this one. I think booleans are a feature of the
> language,
Agreed. The proposed constants "OK" and "DECLINED"
should therefore be 0 and 1 respectively which makes
the whole thing dwimmy.
But for future features constants may be helpful (see
Mike's comment above).
> where constants are something added on by the
> programmer, you
> don't really gain that much by redefining booleans and it
> would clutter
> the syntax.
>
> >
> > > 3. What a about message redirection? Are there plans for the
> > > future that a filter (or whatever) can forward a message to
> > > another appender?
> > >
> > Interesting feature, I haven't thought of that yet (neither have the
> > log4j folks). I gotta think about that. Can you imagine a use case?
> > Also, we could implement that either as a Log4perl-centric
> feature based
> > on filter return code (as you suggested) or as a
> function/method call
> > inside the filter (redir_to_appender(blah)).
>
> Interesting indeed, but I forsee that as being really hairy.
> Do we want
> to write our own JMX api?
why not ;-)? I am really jealous of that feature...
> You have to deal with things like circular
> routes, appenders not being defined/avaliable. Ugh.
Two ways to circumvent this:
1. Every appender has a "level" and forwarding is only allowed
to appenders with a higer level (not specifying a "level" is the
the same as specifying the minimum level).
2. Every message carries a TTL field which is decremented and
the message is discarded if the counter drops to 0.
I prefer the first option.
Mike asked for the use cases.
An appender is a kind of output channels and the reasons
to change an output channel is a moving or changing message
recipient. This is helpful for
- multiple support groups (e.g. applications are administered
by another group during weekends)
- message escalation
- travelling recipient (get log messages via email from 8h-18h
and on your mobile from 18h-22h)
Regards,
Peter
--
Dr. Peter Dintelmann
Dresdner Bank AG
CC IT MIS - MIS@ Products
Theodor-Heuss-Allee 110
D-60301 Frankfurt
Germany
Tel.: +49-(0)69-263-19722
Email: Pet...@dr...
http://www.dresdner-bank.com
http://mis.dresdner-bank.com
|
|
From: <msc...@ao...> - 2003-03-09 18:54:51
|
I've thought a bit more about the OK and DECLINED constants and was almost ready to put them in -- but then I realized that I would have to put them into the main: package, because the sub {...} filters are running in main: so people can use subroutines they've defined in main. I don't want Log4perl inject OK to main, though, that's too intrusive, so I'll leave them out unless someone comes up with a smart idea.
Regarding renaming the decide() subroutine, the only catchy naming idea I had stressing the binary nature of the call was ok() or approve(). Log4perl would call every custom filter's ok()/approve() method to determine the result of a Boolean filter. On the other hand, at least one developer I know of has already been using the new interface -- any newly developed custom filters would have to be adapted. Using the standard custom filters that ship with Log4perl will be possible without code changes. Votes?
--
-- Mike
############################
# Mike Schilli #
# log...@pe... #
# http://perlmeister.com #
# log4perl.sourceforge.net #
############################
|
|
From: Kevin G. <ke...@go...> - 2003-02-22 17:04:57
|
Mike Schilli wrote:
> Pet...@Dr... wrote:
>
> > I prefer to define constants for the return values (and put
> >
> Nice. Definitely the correct way of defining it and being flexible to
> add stuff in the future. On the other hand, I really like constructs like
>
> sub { /x/ and /y/ }
I agree with Mike on this one. I think booleans are a feature of the
language, where constants are something added on by the programmer, you
don't really gain that much by redefining booleans and it would clutter
the syntax.
>
> > 3. What a about message redirection? Are there plans for the
> > future that a filter (or whatever) can forward a message to
> > another appender?
> >
> Interesting feature, I haven't thought of that yet (neither have the
> log4j folks). I gotta think about that. Can you imagine a use case?
> Also, we could implement that either as a Log4perl-centric feature based
> on filter return code (as you suggested) or as a function/method call
> inside the filter (redir_to_appender(blah)).
Interesting indeed, but I forsee that as being really hairy. Do we want
to write our own JMX api? You have to deal with things like circular
routes, appenders not being defined/avaliable. Ugh.
--
Happy Trails. . .
Kevin M. Goess
(and Anne and Frank)
904 Carmel Ave.
Albany, CA 94706
(510)525-5217
|
×
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