The goal was to get events generated by LogUI's logger calls to route to its own tab called "chainsaw-log".
Ideally, other events which were handed over to Chainsaw via a receiver, but
which didn't have the hostname & application properties defined would end up on
a separate tab ("-" instead of "chainsaw-log").
I don't think this was actually happening with log4j 1.3 head anyway, so I can
live with all events which don't have those two properties ending up on the
chainsaw-log tab, if I have to.
I experimented with using MDC.set in place of the
loggerrepositoryex.setproperty calls in LogUI. It didn't work to just change
the calls there - I actually had to call MDC.set in the ChainsawAppenderHandler
constructor (which is who eventually processes the events).
I'm not sure if that's a bug, but it may be.
I'm going to commit the new pom.xml dependency in Chainsaw on the
pattern-layout companion, but I'm going to wait to hear more from others before
I do something about the MDC stuff.
Scott Deboy
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR 97201
Telephone: 503.224.7496
Cell: 503.997.1367
Fax: 503.222.0185
[EMAIL PROTECTED]
www.comotivsystems.com
-----Original Message-----
From: Curt Arnold [mailto:[EMAIL PROTECTED]
Sent: Sun 6/10/2007 11:58 AM
To: Log4J Developers List
Subject: Re: logger repository properties & loggingevent
On Jun 10, 2007, at 2:57 AM, Scott Deboy wrote:
> log4j 1.3 included the ability to set properties at the logger
> repository level (if it was a loggerrepositoryex) - logger
> repository properties would be added to all events associated with
> the repository.
>
> That feature isn't currently available in the 1.2.15 codebase, and
> I was curious if it's something that we want to avoid because of
> backward compatibility issues, or if it's ok to add the feature
> back in.
>
> In Chainsaw, we use this feature to get all chainsaw-specific
> logging events to route by default to a chainsaw-log tab.
>
log4j 1.3 reworked LoggingEvent significantly and introduced the
serialization incompatibilities. I'm not sure how many of those
changes were related to repository properties. I looked at the
log4j 1.2 code and it looked like the easiest way would be to modify
LoggingEvent.getMDC() and LoggingEvent.getMDCCopy() to get the
logger's repo and then check for LoggerRepositoryEx. However, before
risking introducing an unintended side-effect on a significant code
path, I'd really like to understand the immediate need of Chainsaw
and try to find another approach would not have the same potential
for calamity.
The only place LoggerRepositoryEx.setProperty() was used seemed to be
around line 338 in o.a.l.chainsaw.LogUI. Is there a specific reason
why calling MDC.set() would not work?
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
