This actually has a few subtle challenges: 1. The exception stack-trace code can be littered with quotes that will require proper character escaping, so there needs to be a way to guarantee that the resultant message string is able to be inserted.
2. Stack traces can be very long, often longer than typical VARCHAR sizes (4000 for Oracle, 8000 for SQLServer), so unless these are inserted into BLOBs or CLOBs, the stack trace will need to be truncated. Unfortunately, the PatternLayout format modifier truncates *from the beginning* of the string, which for normal Java stack trace output could remove the trace where the exception actually occurred, generally the most important part of the trace. We got around this issue by introducing a new pattern conversion character (%z) and in our PatternConverter subclass' convert() method we unwind the stack trace in reverse so the when the truncation happens, only the tail-end is eliminated. There is of course always the issue of losing some information, this has never been a problem. ----- Original Message ----- From: "Ceki G�lc�" <[EMAIL PROTECTED]> To: "Log4J Users List" <[EMAIL PROTECTED]> Sent: Thursday, June 06, 2002 1:02 PM Subject: Re: Log4j JDBCAppender > > At 09:28 06.06.2002 -0700, you wrote: > >The double quote should fix #2. Any time you are putting a string into a > >varchar type field you should use either single or double quotes. Without > >quotes you'll have all sorts of errors. As for performance successful > >statements will always go faster than failed statements :) > > > >The preparedStatement option seems nice in theory but I believe doesn't > >merit the work: > > > >1) The configuration would need to be more complicated to properly handle > >the variety of types/values/etc you might want to set. > >2) Escaping is still a problem, b/c the appender has to handle any number > >of quotes in a general fashion (unlike your example where you know exactly > >how many and where the quotes are) > >3) The performance value of preparedStatements is debate-able. > >4) Batch inserts make far more difference and will be included very soon > >(it's being tested) > > Kevin, > > I have very briefly looked at the new JDBCAppender. It seems that it > still does not address bug #8529 > (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8529). It should be > fixed soon or otherwise I will have to mark it (JDBCAppender) as > unreliable. > > > -- > Ceki > > SUICIDE BOMBING - A CRIME AGAINST HUMANITY > Sign the petition: http://www.petitiononline.com/1234567b > I am signatory number 22106. What is your number? > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
