RE: [log4perl-devel] RFC: Log4perl Custom Filters Design Proposal

[Dintelmann, P. <Pet...@Dr...>]

> 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