Howdy,
Why not use the Mapped Diagnostic Context (MDC) to hold your event identifier and
message code? Then include %X{messageCode} and %X{eventIdentifier} in your pattern.
You wouldn't have to override LoggingEvent nor PatternParser.
Yoav Shapira
Millennium ChemInformatics
>-----Original Message-----
>From: Lutz Michael [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, February 04, 2003 11:39 AM
>To: 'Log4J Users List'
>Subject: RE: "forcing" a logging call
>
>
>
>Ceki,
>
>One more thing, if I may.
>
>We have requirements to pass additional information into Logging on every
>log call, such as (a) a message code and (b) a unique event identifier, in
>addition to (c) the message. Additionally, we're generating hostname and
>hostaddress via additional conversion characters.
>
>Thus, we extended LoggingEvent to carry around this additional information,
>and since Category determines what LoggingEvent type to pass down into
>Log4j
>(via callAppenders), we overrode forcedLog to pass our extended
>LoggingEvent.
>
>I basically stumbled on this approach at
>http://www.ingrid.org/jajakarta/log4j/jakarta-log4j-
>1.1.3/docs/deepExtension
>.html by Paul Glezen, I'm sure you're familiar with it. His approach is
>slightly different, since he's passing information into the category
>factory, and we need to pass our additional information in on every log
>call.
>
>In total, we've overridden 5 classes - Logger, LoggerFactory, LoggingEvent,
>PatternLayout, and PatternParser. We have a couple helper classes as well.
>
>Given this ... are we still in left field ... or is our general approach
>sound.
>
>Look forward to your response,
>Mike
>
>PS Sorry about taking up so much of your time on this, but it's important
>we
>do the right thing.
>
>
>
>
>-----Original Message-----
>From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, February 04, 2003 11:10 AM
>To: Log4J Users List
>Subject: RE: "forcing" a logging call
>
>
>At 09:55 04.02.2003 -0500, Lutz Michael wrote:
>
>>Ceki,
>>
>>You rock! That worked.
>
>Somewhat exaggerated qualification but thanks.
>
>>So, basically what we did was:
>>
>>1) Extend Logger, because we needed to add a public "force(Object
>message)"
>>routine to call "callAppenders" directly.
>>2) Extend LoggerFactory, to return our own Logger.
>>3) We then casted the Logger returned by the Factory to our own extended
>>Logger type. We needed to do this because the base Logger doesn't know
>>about our new "force" method.
>>
>>Does this sound correct to you, or is this over-complicated?
>
>Note the implementation of forcedLog:
>
> protected void forcedLog(String fqcn, Priority level, Object message,
>Throwable t) {
> callAppenders(new LoggingEvent(fqcn, this, level, message, t));
> }
>
>Instead of sub classing Logger which is usually a very bad idea on the long
>term, I'd wrap Logger as explained the complete manual (which you already
>have). Oh, although forcedLog() is protected callAppenders() is public!
>
>>Thanks again for your help!
>>
>>Mike
>>
>>
>>-----Original Message-----
>>From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
>>Sent: Tuesday, February 04, 2003 4:09 AM
>>To: Log4J Users List
>>Subject: Re: "forcing" a logging call
>>
>>
>>Mike,
>>
>>See the Category.forcedLog and and Category.callAppenders methods. Have a
>>look at the source code as well.
>>
>>At 00:10 04.02.2003 -0500, Lutz Michael wrote:
>>
>>
>> >Is there a way to force a logging call to go through, regardless of what
>> >level is set?
>> >If I have to extend classes to achieve this, I'll do it.
>> >I'm having trouble finding a way to do this.
>> >
>> >Thanks in advance.
>> >
>> >Mike
>> >
>>
>>--------------------------------------------------------------------------
>-
>>----
>> >This message and any included attachments are from Siemens Medical
>>Solutions
>> >Health Services Corporation and are intended only for the addressee(s).
>> >The information contained herein may include trade secrets or privileged
>or
>> >otherwise confidential information. Unauthorized review, forwarding,
>> >printing,
>> >copying, distributing, or using such information is strictly prohibited
>> >and may
>> >be unlawful. If you received this message in error, or have reason to
>> >believe
>> >you are not authorized to receive it, please promptly delete this
>message
>>and
>> >notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>--
>>Ceki
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>--------------------------------------------------------------------------
>-
>----
>>This message and any included attachments are from Siemens Medical
>Solutions
>>Health Services Corporation and are intended only for the addressee(s).
>>The information contained herein may include trade secrets or privileged
>or
>>otherwise confidential information. Unauthorized review, forwarding,
>>printing,
>>copying, distributing, or using such information is strictly prohibited
>>and may
>>be unlawful. If you received this message in error, or have reason to
>>believe
>>you are not authorized to receive it, please promptly delete this message
>and
>>notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>
>--
>Ceki
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>---------------------------------------------------------------------------
>----
>This message and any included attachments are from Siemens Medical
>Solutions
>Health Services Corporation and are intended only for the addressee(s).
>The information contained herein may include trade secrets or privileged or
>otherwise confidential information. Unauthorized review, forwarding,
>printing,
>copying, distributing, or using such information is strictly prohibited and
>may
>be unlawful. If you received this message in error, or have reason to
>believe
>you are not authorized to receive it, please promptly delete this message
>and
>notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
