You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Kevin Steppe <ks...@pacbell.net> on 2002/06/06 19:47:06 UTC

Error Handler & Log4j JDBCAppender

I ran some tests to generate errors in flushBuffer() [lines 226-280]. 
 The first instance of errorHandler.error generated some console output. 
 The second instance (line 267) did not generate anything.  I did not 
specify any particular errorHandler.  When I placed a System.out.println 
inside that catch block I got it's output.  Thus it appears that by 
default the error call on line 267 will not generate output.  

Could you advise me or look at what is happening here?

Re: Bug --
No, the last JDBCAppender I sent you did not fix the bug.  I am working 
on that right now.



Ceki Gülcü wrote:

>
> 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:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
>
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: PatternLayout extensions & Log4j JDBCAppender

Posted by Ceki Gülcü <ce...@qos.ch>.
There is an example in examples/ directory. Adding a new conversion
character is indeed a natural continuation of your current approach
which I must say is ill advised.

Escaping quotes is one issue that PreparedStatements solve trivially.
PreparedStatements are a mandatory part of the JDBC spec while Batch
statements are optional.  MySQL does support PreparedStatements.

Log4j components have to be absolutely reliable. There are many cool
features that we do not implement because they cannot be implemented
reliably. JDBCAppender must adhere to the same guidelines.

At 11:47 06.06.2002 -0700, Kevin Steppe wrote:
>After digging into the throwable info in a JDBCAppender a littler here is 
>my current idea:
>
>Use an extension to the PatternLayout, which can convert the throwable 
>into a single string (with colons, or \n, or whatever in between).  This 
>new conversion character code then be placed in the normal sql such as:
>insert into log (message, trace) values ('%m', '%throw')
>
>I remeber reading that custom conversions are fairly easy.  Anyone have a 
>pointer for me?
>
>Kevin

--
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


PatternLayout extensions & Log4j JDBCAppender

Posted by Kevin Steppe <ks...@pacbell.net>.
After digging into the throwable info in a JDBCAppender a littler here 
is my current idea:

Use an extension to the PatternLayout, which can convert the throwable 
into a single string (with colons, or \n, or whatever in between).  This 
new conversion character code then be placed in the normal sql such as:
insert into log (message, trace) values ('%m', '%throw')

I remeber reading that custom conversions are fairly easy.  Anyone have 
a pointer for me?

Kevin


Ceki Gülcü wrote:

>
> At 10:47 06.06.2002 -0700, you wrote:
>
>> I ran some tests to generate errors in flushBuffer() [lines 226-280]. 
>> The first instance of errorHandler.error generated some console 
>> output. The second instance (line 267) did not generate anything.  I 
>> did not specify any particular errorHandler.  When I placed a 
>> System.out.println inside that catch block I got it's output.  Thus 
>> it appears that by default the error call on line 267 will not 
>> generate output.
>>
>> Could you advise me or look at what is happening here?
>
>
> Does OnlyOnceErrorHandler ring a bell? :-)
>
>> Re: Bug --
>> No, the last JDBCAppender I sent you did not fix the bug.  I am 
>> working on that right now.
>
>
> Excellent. I am looking forward for the resolution of this bug.
>
>
> -- 
> 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:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
>
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Error Handler & Log4j JDBCAppender

Posted by Kevin Steppe <ks...@pacbell.net>.

> Does OnlyOnceErrorHandler ring a bell? :-)

*slow nod of understanding*

Thanks.

Kevin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Error Handler & Log4j JDBCAppender

Posted by Ceki Gülcü <ce...@qos.ch>.
At 10:47 06.06.2002 -0700, you wrote:
>I ran some tests to generate errors in flushBuffer() [lines 226-280]. The 
>first instance of errorHandler.error generated some console output. The 
>second instance (line 267) did not generate anything.  I did not specify 
>any particular errorHandler.  When I placed a System.out.println inside 
>that catch block I got it's output.  Thus it appears that by default the 
>error call on line 267 will not generate output.
>
>Could you advise me or look at what is happening here?

Does OnlyOnceErrorHandler ring a bell? :-)

>Re: Bug --
>No, the last JDBCAppender I sent you did not fix the bug.  I am working on 
>that right now.

Excellent. I am looking forward for the resolution of this bug.


--
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>