> 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]
