At 23:06 27.05.2002 -0700, Kevin Steppe wrote: >>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 and thus an acceptable reference for log4j.
Isn't the JDBC 3.0 very recent? How can the new features of a recent spec. can be compatible with previous versions of the spec? I better read JDBC 3.0 before asking other silly questions. >>We could state the requirements on the database structure without >>creating it. This is somewhat similar to the JDBC Realm in Tomcat. See >>http://jakarta.apache.org/tomcat/tomcat-4.0-doc/realm-howto.html for more >>details. > >I will read up on this in the next day or so. Excellent. It will take you about 45 seconds. >>>Have a two-layer solution. First a totally flexible JDBCAppender, such >>>as the current implementation, for the sql savvy user. Second, build a >>>defined-table implementation on top of that -- as a subclass or >>>whatever. This way the savvy user gets some core functionality, the >>>basic user gets a well verified implementation, and other components >>>have a table definition they can write to. >> >>How is the current implementation of the JDBCAppender (based on >>patterns) compatible with batch statements? Am I missing something >>here? > > >the addBatch(String sql) command will take any sql statement (including >the current layout-based creations) and place them all into a batch for >execution. This could (and should) be done within the flushBuffer() >method of the JDBCAppender. Use of addBatch would of course be contingent >on the DatabaseMetaData indicating support for it. This would take a >small update to the current code. Would end of the week be early enough >for this improvement? Time is almost never an issue in log4j development. We deliver good software when it is good and ready. Since log4j is used by so many developers to detect and isolate problems, log4j itself must be reliable. Thus, it is better to take your time and not rush. Of course, this does not mean we can fall asleep either... :-) The JDBCAppender must also log exceptions (throwables to be exact) if the logging event contains any. We can't just ignore bug #8529 forever, can we? (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8529) >For other things: > I can put forward an example of my two-tier idea sometime in June. I > could include a Retriever implementation at that time as well if log4j > developers want to go that direction. The Retriever idea is very sound although at this stage I am more concerned about the JDBCAppender implementation. -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
