| Summary: | Would like to use Filter's as TriggeringEventEvaluator's for SMTPAppender | ||
|---|---|---|---|
| Product: | Log4j - Now in Jira | Reporter: | sschwell |
| Component: | Appender | Assignee: | log4j-dev <log4j-dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | carnold |
| Priority: | P2 | ||
| Version: | 1.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Bug Depends on: | |||
| Bug Blocks: | 42823 | ||
Should reconcile this with o.a.l.rolling.TriggeringPolicy which has similar semantics (but provides more than just the event to make the decision). A possible solution would be to have RFA check for TriggeringPolicy and if not found check for TriggeringEventEvaluator and wrap the TEE to provide the TP interface. Ideally Filter (or the Filter proxy) would support both interfaces. *** Bug 42823 has been marked as a duplicate of this bug. *** Added SMTPAppender.setEvaluator() to programatically set TriggeringEventEvaluator and added support for nested triggeringPolicy elements in XML configuration. The org.apache.log4j.rolling.FilterBasedTriggeringPolicy in the extras companion now supports org.apache.log4j.spi.TriggeringEventEvaluator in addition to org.apache.log4j.rolling.TriggeringPolicy and can be used with both RollingFileAppender and SMTPAppender to trigger based on filters. |
There are already a few useful implementations of Filter. It would be nice if we could also use those implems as TriggeringEventEvaluator's for SMTPAppender. This would be trivial to accomplish by having Filter implement TriggeringEventEvaluator interface and adding the following method to Filter: public boolean isTriggeringEvent(LoggingEvent event) { return (decide(event) == ACCEPT); } Related to this - it would be nice if DOMConfigurator allowed specification and config of TriggeringEventEvaluator's for SMTPAppender, similarly to how it allows Filters to be specified. Thanks, Steve