JDBCAppender

his would return the connection to the pool it * came from. * *Override getLogStatement(LoggingEvent event) to produce specialized or * dynamic statements The default uses the sql option value * * @author: Kevin Steppe (mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED])

Re: JDBCAppender

I suppose that's possible, according to Sun however, ArrayList is preferred (and faster). How important is it? Kevin Ceki Gülcü wrote: > Kevin, > > Is it possible to use Vector instead of ArrayList in order to > keep JDK 1.1 compatibility? > > -- > Ceki > > My link of the month: http://java.sun

Re: JDBCAppender

I have attached the new version using Vector instead of ArrayList -- turned out to be easier than I expected. Personally, I think people should get up to JDK1.3 or so... Kevin Ceki Gülcü wrote: > Well, it's rather important because otherwise log4j does not compile > not run under JDK 1.1.x. S

Re: RollingFileAppender and DailyRollingFileAppender

Ceki, Hadn't seen the 1.3 plan. Strategy based rollovers looks interesting -- I'll get to work on it. What specifically needs to be done to release 1.2? The user list is getting a lot of traffic on problems in 1.1.3 that are fixed in 1.2. I think the most effective action to reducing u

Re: Fwd: DO NOT REPLY [Bug 8529] New: - JDBCAppender doesn'ttakethrowable stack trace

This is tougher for the JDBCAppender than others. For file output it is possible to simply write out a few more lines of text. This doesn't work for a db. The format is different from the regular messages and so has to be handled differently. I'll start working/thinking on this, but any ideas

Re: JDBCAppender performance

Performance questions--- First off, databases are pathetically slow compared to file or memory writes. If you have a performance critical application avoid a database where-ever possible. Ironicly, this is true even for database driven applications -- you'll get better performance by reduc

Re: Comments on JDBCAppender

Ceki et al., First, my apologies for being terse in my message, I'm just short on time this month. Problems: addBatch is an optional method in Statement. It is not guarenteed to be implemented by all drivers (in fact it is not implemented in the mySQL driver I use). Your logEvents ta

Re: Comments on JDBCAppender

> >> Problems: >> addBatch is an optional method in Statement. It is not guarenteed >> to be implemented by all drivers (in fact it is not implemented in >> the mySQL driver I use). >> Your logEvents table definition is not valid on all databases. And >> in fact it's not valid on -most-

Re: Comments on JDBCAppender

Niclas Hedhman wrote: > Sorry, but I don't buy this argument. > SQL is by default an evil thing and should not be exposed to users, nor > programmers. That is rather opinionated, just like the following: SQL is by default an incredibly elegant, simple, and powerful programming language -- in

Re: Comments on JDBCAppender

Niclas Hedhman wrote: > On Friday 24 May 2002 23:37, Kevin Steppe wrote: > >> Niclas Hedhman wrote: >> >>> SQL is by default an evil thing and should not be exposed to users, nor >>> programmers. >> >> That is rather opinionated, just like t

Re: Comments on JDBCAppender

> > Thank you very much. You can find the JDBC 2.0 spec at > http://java.sun.com/products/jdk/1.2/docs/guide/jdbc/index.html Note > that there is no section 6.2 in this version of the spec. I think we should be working off the 3.0 spec at this point. It is intended to be backwards compatible

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 t

Re: Error Handler & Log4j JDBCAppender

> Does OnlyOnceErrorHandler ring a bell? :-) *slow nod of understanding* Thanks. Kevin -- To unsubscribe, e-mail: For additional commands, e-mail:

PatternLayout extensions & Log4j JDBCAppender

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

Re: DailyRollingFileAppender problems

Robin, This is a known feature/bug for the DailyRollingFileAppender. You have two options to get around this. First in the cvs is a CompositeRollingAppender which will do this for you -- you could also use it as a RollingFileAppender or combined, hence Composite. Second, a few weeks back so

Re: newbie question about RollingFileAppender

Nothing in Log4J that does that right now -- you'd have to modify something yourself. I'd suggest taking CompositeRollingAppender (from the cvs) and put the rollOverTime() code into the rollOverSize() method. If you can wait a few days I'll put some code together for it. Kevin Alexander Cerna

Re: newbie question about RollingFileAppender

es would be nice * but is not yet implemented. * * @author Kevin Steppe * @author Heinz Richter * @author Eirik Lygre * @author Ceki Gülcü */ public class CompositeRollingAppender extends org.apache.log4j.FileAppender { // The code assumes that the following 'time' constants a

Re: Developing and contributing code

Manik/Ceki, I haven't followed this conversation in depth so ignore me if my comments are obviously out of place. However, it is important to realize that if an appender fails once or even many times the user may still want it attached. For example a JDBCAppender may fail due to

Re: Database target for log output

Try contribs/KevinSteppe/JDBCAppender or contribs/ThomasFenner/* for DB appenders. You can search in the archives for "JDBCAppender" and you should find some discussion and help over the last year or so. Kevin Steppe [EMAIL PROTECTED] wrote: > Hello, > > Is it pos

Re: DailyRollingFileAppender.

That I know of several different fixes for this bug have been suggested/posted/etc -- though I haven't looked at the ones other than mine. This bug has been around for a long time now, and numerous people have complained about it. It would be very nice if the commiters (hint Ceki) would make s

Re: [POLL] Commercial documentation

Ceki, I basicly agree with Jon on this one. Documentation, like the current manual, I prefer to see as part of the project. However, a book on log4j -- how it works, how to modify it, etc with more extensive code examples as such -- would certainly be something appropriate to do for-profit o

Re: [POLL] Commercial documentation

Ceki Gülcü wrote: > At 12:31 10.01.2002 -0800, you wrote: > >Ceki, > > > >I basicly agree with Jon on this one. Documentation, like the current manual, I >prefer to see as part of the project. However, a book on log4j -- how it works, how >to modify it, etc with more extensive code examples