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).
Well, in terms of cleaner code, I don't think that introducing inner classes is the way to go. Personally I think it will be much easier for the end-user to understand that if they are using a DataSource from JNDI they use the JNDIPreparedStatementAppender with set A of options and if they are using the traditional DriverManager they use URLPreparedStatementAppender (I'm open to suggestions on the name) with set B of options. They never need to know that there is an abstract class that contains the common code. Furthermore, it provides a clean way for an end-user to customize how they get their Connections if they are implementing pooling or such things themselves (i.e. extend the class and implement the getConnection() method).
Executing in a separate thread has consequences from within an EJB container (i.e., it's a no-no).
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.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
