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]
