Hi Inner classes are a bad thing, maily becase they are not protected in the same way as regular classes.
I think that the abstract class aproach is a good idea. I take it that the configuration can be done through the log4j properties fil. Hermod -----Opprinnelig melding----- Fra: Paul Smith [mailto:[EMAIL PROTECTED] Sendt: 1. april 2003 05:18 Til: 'Log4J Developers List' Emne: RE: JDBC Appender > I figured > I would have an abstract base class with an abstract getConnection() > class and two concrete derivatives; one for getting the > connection from > a JNDI context and one for getting the connection from the > DriverManager. This isn't too bad an idea, but I'm personally against an Abstract class here (and I'm no committer so take this with a grain of salt). What would be ideal is if the configuration of the JDBCAppender could be specified with an option that describes the Strategy to obtain a Connection. Just like you provide a Layout impl for an appender as a attribute. This way you have a single class, but have smaller inner classes with the different ways of getting the connection. I think this ends up being cleaner code, and easier to understand (I think a lot of people get lost with inheritence, and by that I include me). > 1) The original JDBCAppender class has a buffer where it stored the > events until a limit is hit. I'm not sure I understand the rationale > behind this. Doesn't this cause most loggings to be fast but > once in a > while one client pays the bill for the rest? It also seems > to have been > a source of bugs in the past. Does anyone have a compelling > reason for > including it in the new appenders? You have a good point on the penalty (not sure if it does this, but if it does, it is bad). What would be more ideal is to buffer the events till some threshold, as it happens now, but when commiting the results to the JDBC connection, do this in a separate thread. cheers, Paul Smith --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that DnB cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the virus programs used in the DnB Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
