logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: A Multiplex Appender
Date Fri, 15 Oct 2004 10:05:38 GMT


This sounds really excellent.

I don't think o.a.l.rolling.multiplex.MultiplexRollingFileAppender has
much   to   do   with   rolling   but   mostly   about   multiplexing.
MultiplexFileAppender       could       multiplex       FileAppenders,
RollingFileAppenders,  SyslogAppenders,  DBAppenders,  so  on  and  so
forth.    Using   Joran's   implicit   rules,   you   can   attach   a
MultiplexAppenderFactory in  config files quite  easily.  For example,
you   would   most  probably   want   to   pass   parameters  to   the
MultiplexAppenderFactory instance  and that can  be accomplished  with
the help of Joran. See DBApepnder and ConnectionSources for an example.

So, to answer your questions:

1) You should commit.
2) No need to go through the sandbox.

3) Separating the mutiplexing from the  rolling would be a good design
choice. Having  MultiplexAppender being able to  encapsulate all sorts
of appenders would offer much more flexibility.


At 06:15 AM 10/15/2004, Paul Smith wrote:
>Hi all,
>I've been mulling over this whole "I need logs from each User to go in their
>own Log file" problem that crops up from time to time.  It seems to be a
>common request, even if many of us actually do this differently (e.g. use
>MDC in the PatternLayout to interleave the logs).
>Anyway, I have been playing around for the last couple of days with a
>MultiplexRollingFileAppender, which I think might be useful for inclusion in
>org.apache.log4j.rolling.multiplex.MultiplexRollingFileAppender extends from
>AppenderSkeleton (it's possibly badly named, and might benefit from being in
>a different package)
>It is given an instance of a MultiplexSelector instance which the appender
>uses to "select" which internal appender should be used for a LoggingEvent,
>should this selector not have anything to match, the Selector uses an
>instance of an AppenderFactory (also set as a property on
>MultiplexRollingFileAppender) to create one and register with the internals
>of the Selector.
>For convenience I've then given MultiplexRollingFileAppender some special
>properties that can automatically create a selector based on an MDC key
>value (say "User" for selecting an appender based on the MDC value mapped to
>the "User" key).  You can also set the class name of the AppenderFactory to
>use as a property in the same way as the ObjectRenderer is created, and I've
>created some utility methods in an AppenderFactoryUtils class that can
>create an AppenderFactory that uses the MDC key of choice and rolls daily
>(probably the most standard pattern) so that all the user needs to do is
>create a simple impl of AppenderFactory to delegate to the utility methods
>if that matches their use case.
>To summarise how I would see the user configuring this in, say
>The user would then need to create the MyMultiplexAppenderFactory class as
>so (this example creates a non-rolling simple FileAppender):
>public class MyMultiplexAppenderFactory implements AppenderFactory {
>         public Appender create(LoggingEvent e) {
>                 String mdcKey = e.getProperty("User");
>                 return AppenderFactoryUtils.
>                                 createSimpleMDCbasedFileAppender(
>                                         mdcKey,
>                                         new PatternLayout("%m%n")
>                 );
>         }
>Using the above would create files like:
>All based on the value of the MDC key requested.
>The source code for all this is all sitting ready to commit.  I have some
>basic test-cases, but I wouldn't call them comprehensive, and the JavaDoc
>needs a fair bit of work.  Since the AppenderFactory isolates how the
>appender is created, one isn't forced to use an Appender of any type, and
>you can create your own as needed , this is why it probably should not have
>the word "rolling" in it, no should it probably sit in this package.  I
>could create a sub-class that did the standard pattern of just using a MDC
>Key value, and always rolling every night for those users who want things
>1. Should I bother committing this?
>2. If so, should it go in the sandbox first?
>3. Any thoughts on the design etc?
>Paul Smith
>To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org

Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message