logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aditya Prasad" <akpra...@gmail.com>
Subject Re: Thread-specific appenders
Date Wed, 17 Oct 2007 16:18:09 GMT
Ah, yes, that was my first approach.  But then it's more painful to
watch them separately in real time, it requires more than a simple
'grep' if I have multi-line output (probably more work than the
TLAppender class to write), and I wanted a 'slicker' solution :)

Thanks!
Aditya

On 10/17/07, Paul Smith <psmith@aconex.com> wrote:
> yep, but I have a 'simpler' implementation for you.  If you're trying
> to seperate logs out by thread, do you _really_ need a file per
> thread?  Couldn't each line in the log file simply contain the
> Thread's name via the PatternLayout's %t ?  That way can visually
> distinguish logs relating to each thread anyway.
>
> just a thought, much easier to do! :)
>
> Paul
> On 17/10/2007, at 2:22 PM, Aditya Prasad wrote:
>
> > Ah, the XML configuration syntax is much richer than in
> > log4j.properties!  That could be useful.  I think your example makes
> > sense, and would be useful in a more general setting.  I may even end
> > up mimicking it at some point.
> >
> > For my own project, I'm content with making it stick with a
> > FileAppender whose properties I'm willing to hard code for now.  The
> > only functionality I'm trying to add is multiplexing based on the
> > thread.  Given that scenario, does my impl make sense?
> >
> > Cheers,
> > Aditya
> >
> >
> > On 10/16/07, Paul Smith <psmith@aconex.com> wrote:
> >> I started work on a Multiplexing Appender a while back that had a
> >> similar reason to exist (some people want files-per-level, for what
> >> reason I have no idea).  I got stuck.
> >>
> >> Unfortunately there's no way in the configuration mechanism at the
> >> moment to register a 'factory' for appenders which is what one really
> >> needs here.  THe appender one would register in the configuration
> >> needs to be given enough information to know how to create real
> >> internal appenders as needed.
> >>
> >> The only way I could think of doing this would be to have a property
> >> on the 'factory' appender that indicates the name of a 'prototype'
> >> appender which is assumed to have been defined in the configuration
> >> and available somewhere.  The factory appender could use the
> >> properties defined on that appender as a base, and modify as needed
> >> (tweak the filename based on thread for example).
> >>
> >> Hacking out a demonstration log4j.xml config file (with no regard for
> >> whether it's syntactically quite correct...)
> >>
> >> <log4j:configuration debug="false" threshold="debug"
> >> ....
> >>      <appender name="Prototype"
> >> class="org.apache.log4j.DailyRollingFileAppender">
> >>          <param name="File" value="${catalina.home}/logs/
> >> prototype.log" />
> >>          <param name="Append" value="true" />
> >>          <param name="DatePattern" value="'.'yyyy-MM-dd" />
> >>          <layout class="org.apache.log4j.PatternLayout">
> >>              <param name="ConversionPattern"
> >>                  value="[%d{ISO8601} %-5p][%20.20c][%t][%X
> >> {IPAddress}]
> >> [%X{UserID}] %m%n"
> >>                  />
> >>          </layout>
> >>      </appender>
> >>
> >>      <appender name="ThreadLocalAppender"
> >> class="com.you.FunkyThreadLocalAppender">
> >>          <param name="prototypeName" value="Prototype" />
> >>
> >>      </appender>
> >> ....
> >>
> >>      <root>
> >>          <level value="INFO" />
> >>          <appender-ref ref="ThreadLocalAppender" />
> >>      </root>
> >> </log4j:configuration>
> >>
> >>
> >> On activateOptions(), your ThreadLocalAppender implementation could
> >> search the log4j appender registry for the prototype and sort of
> >> clone/copy the properties and perhaps 'fudge' the filename as
> >> needed.  I originally thought of embedding MessageFormat style syntax
> >> in the filename property of the prototype appender, but in this case
> >> log4j is going to try to create the appender's file, which I think
> >> having a '...{0}...' style syntax is going to cause errors. But since
> >> the prototype appender is never used (notice it's not referenced to a
> >> connected logger in the above), the error is benign.
> >>
> >>
> >> thoughts?
> >>
> >> cheers,
> >>
> >> Paul
> >> On 17/10/2007, at 1:40 PM, Aditya Prasad wrote:
> >>
> >>> Hi all,
> >>>
> >>> I've written an appender that writes to different files based on the
> >>> caller's thread id, but I'm not sure I've done it the best way.
> >>> Here's my scenario:
> >>>
> >>> I have a JUnit test driver that runs about 50 tests from a suite.
> >>> Because it takes too long to run them sequentially, and they're
> >>> independent, I am running them in parallel (one per thread).  I
> >>> would
> >>> like their outputs to go to different files.  Since much of the
> >>> logging is being performed by third-party software (e.g.,
> >>> HttpClient),
> >>> I can't simply create a different logger for each test.
> >>>
> >>> So I've created a ThreadLocalFileAppender, which (as its name
> >>> suggests) has a ThreadLocal instance that stores a FileAppender per
> >>> thread.  The file locations are determined by thread name.  It
> >>> implements the Appender interface, and the method implementations
> >>> simply grab the TL appender and delegate the calls.
> >>>
> >>> Three questions:
> >>>
> >>> 1) Is there an existing class I should be using instead?
> >>>
> >>> 2) Should I not have implemented Appender directly?  I thought about
> >>> extending FileAppender so I could expose its interface, but
> >>> AppenderSkeleton has final methods that I probably want to override.
> >>>
> >>> 3) Can I not set properties (like the Layout) via
> >>> log4j.properties if
> >>> I do this?  It doesn't seem to work.  (In fact, I can't find any
> >>> good
> >>> documentation on how exactly log4j.properties performs its magic.  I
> >>> figured it was a simple IoC pattern, but it appears it's not).
> >>>
> >>> Thanks!
> >>> Aditya
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>
> >>
> >> Paul Smith
> >> Core Engineering Manager
> >>
> >> Aconex
> >> The easy way to save time and money on your project
> >>
> >> 696 Bourke Street, Melbourne,
> >> VIC 3000, Australia
> >> Tel: +61 3 9240 0200  Fax: +61 3 9240 0299
> >> Email: psmith@aconex.com  www.aconex.com
> >>
> >> This email and any attachments are intended solely for the addressee.
> >> The contents may be privileged, confidential and/or subject to
> >> copyright or other applicable law. No confidentiality or privilege is
> >> lost by an erroneous transmission. If you have received this e-mail
> >> in error, please let us know by reply e-mail and delete or destroy
> >> this mail and all copies. If you are not the intended recipient of
> >> this message you must not disseminate, copy or take any action in
> >> reliance on it. The sender takes no responsibility for the effect of
> >> this message upon the recipient's computer system.
> >>
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
>
> Paul Smith
> Core Engineering Manager
>
> Aconex
> The easy way to save time and money on your project
>
> 696 Bourke Street, Melbourne,
> VIC 3000, Australia
> Tel: +61 3 9240 0200  Fax: +61 3 9240 0299
> Email: psmith@aconex.com  www.aconex.com
>
> This email and any attachments are intended solely for the addressee.
> The contents may be privileged, confidential and/or subject to
> copyright or other applicable law. No confidentiality or privilege is
> lost by an erroneous transmission. If you have received this e-mail
> in error, please let us know by reply e-mail and delete or destroy
> this mail and all copies. If you are not the intended recipient of
> this message you must not disseminate, copy or take any action in
> reliance on it. The sender takes no responsibility for the effect of
> this message upon the recipient's computer system.
>
>
>
>

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


Mime
View raw message