In DBAppender: insertStatement.setLong(0, 0); should be insertStatement.setLong(1, 0);
Also, in CustomSQLDBReceiver: Should LoggingEvent event = new LoggingEvent(null, eventLogger, timeStamp, levelImpl, message, threadName, throwableInfo, ndc, locationInfo, properties); be LoggingEvent event = new LoggingEvent(eventLogger.getName(), eventLogger, timeStamp, levelImpl, message, threadName, throwableInfo, ndc, locationInfo, properties); ? In dbreceiverjob: Should we pass a logger name instead of null in loggingevent constructor (same as above)? Question: are we going to support event properties in the 1.2 stream? Being able to populate properties from MDC, throwableinfo and NDC are all pretty important...would be nice if all of the receivers could use this functionality (multicastappender/receiver, etc). 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: Tue 4/17/2007 9:40 PM To: Log4J Developers List Subject: Re: [Patch review please] Further work for Receivers backport to 1.2 On Apr 17, 2007, at 11:27 PM, Curt Arnold wrote: > > On Apr 17, 2007, at 10:42 PM, Paul Smith wrote: > >> Hi all, >> >> I've completed porting the remaining Receiver classes to the >> sandbox area. The below patch is what I have locally, and taking >> the generated jar and adding it as a dependency to Chainsaw makes >> everything compile nicely. I am not able to do any testing on >> this as yet, and figure a patch review is probably worthwhile at >> this stage. >> >> These are all baseline copies from the log4j trunk. The DB* stuff >> needed more fiddling than the others. I had to comment out all >> internal logging statements in the DBAppender because >> AppenderSkeleton in 1.2 does not provide that. There is no >> concept of a sequence # either, so I munged that in the insert >> statement so that all the inserts have '0' as a sequence value. >> Given LoggingEvent in 1.2 doesn't have that anyway, I figure >> that's ok.. >> >> Curty, Scott and others, any chance you could review this please >> before I check it in? >> >> (Note: I'll fix checkstyle issues later, I know there's tabs >> everywhere sorry) >> > > Maybe you could fake out the getLogger() calls like > > private static final class LogLogger { > public void debug(final String msg) { > LogLog.debug(msg); > } > public void warn(final String msg) { > LogLog.warn(msg); > } > public void error(final String msg, final Throwable ex) { > LogLog.error(msg, ex); > } > } > private static final LogLogger getLogger() { > return new LogLogger(); > } > or even better private static final LogLog getLogger() { return new LogLog(); } You could likely get style warnings that you shouldn't access static members using instance member syntax, but it should still work. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
