> 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).
I think it will definately depend on peoples preference, but in the end, it's just a JDBCAppender, with different ways of obtaining a connection (a selectable ConnectionFactory if you will, in fact Mark just intimated the same thing in an email that just popped in). Ideally from a developers and users point of view, the JavaDoc for the single class file would contain all the docs they need to understand it. Using an abstract class and having separate Appender's could lead to inheritence explosion if additional ways of obtaining the Connection are found (i.e. through a separate Pooling implementation). > Executing in a separate thread has consequences from within an EJB > container (i.e., it's a no-no). Indeed, I hadn't thought about that one. Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
