Ceki Gülcü wrote:
> Hi Jason,
>
> It makes sense only to index log messages that are written somewhere. Thus, it only
>makes sense to peek at log events that are handled by an appender as those are the
>only one that have a chance of being ever written. Many other messages are dropped by
>the category instance because of the basic selection rule, i.e. the category instance
>priority must be smaller or equal to the log statement priority.
>
> My initial proposed solution is to attach a org.apache.log4j.spi.Filter that
>consistently returned NEUTRAL but before returning performs Lucene indexing of the
>log event. There are two problems with this approach:
>
> 1) If the Lucene filter is placed first in the filtering chain, then a later filter
>can order to drop an indexed event. Thus, unwritten events are logged.
>
> 2) Filters have only access to org.apache.log4j.spi.LoggingEvent objects, not the
>formatted event.
>
> You might actually not be interested in the formatted event in that case there is
>one easy solution: just sub-class the appender that you would like to index and
>override it's subAppend method. As in
>
> public class IndexedFileAppender extends FileAppender {
>
> // When subAppend is called, we are assured that the
> // event will be logged barring programming or hardware
> // errors
> void subAppender(LoggingEvent e) {
> super.subAppend(e);
> index(e); // do your Lucene indexing here
> }
> }
>
> If you place the index invocation before super.subAppend you have preprocessing.
>
> My main message here is that indexing is best done in the concerned appender. We can
>either add pre-processing and post-processing support to *all* appenders or let the
>appender handle indexing it self. I am more inclined for the latter solution mostly
>to keep the log4j API as small as possible. Do other users want generalized pre- or
>post-append processing? Regards, Ceki
Thanks a lot I will try subclassing the appender I'm working with to give it
a try.
Of the top of my head I can't think of any other cases where you might want
to process the log messages so I will use your suggested approach. Thanks!
>
>
> At 23:06 11.03.2001 -0500, Jason van Zyl wrote:
> >Hi,
> >
> >I was wondering if there was any sort of hook to process a log
> >message before it is actually logged.
> >
> >I would like to index the log messages using Lucene so that
> >the logs are searchable.
> >
> >Where is the best place to grab hold of the contents of
> >a message before it is actually logged?
> >
> >I can do this myself by hacking around but maybe this
> >pre-processing of log messages might be generally
> >useful. Maybe I can already do this. Any pointers?
> >
> >Thanks,
> >
> >--
> >jvz.
> >
> >Jason van Zyl
> >[EMAIL PROTECTED]
> >
> >http://jakarta.apache.org/velocity
> >http://jakarta.apache.org/turbine
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
> I hope to see you at my ApacheCon 2001 presentation
> entitled "Log4j, A Logging Package for Java".
>
> See http://ApacheCon.Com/2001/US/ for more details.
>
> ----
> Ceki Gülcü Web: http://qos.ch
> av. de Rumine 5 email: [EMAIL PROTECTED] (preferred)
> CH-1005 Lausanne [EMAIL PROTECTED]
> Switzerland Tel: ++41 21 351 23 15
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
