Hi With the danger of derailing the subject I do appreciate you thoughts. The discussion of containment vs. inheritance is a long and weildy one and better done some somewhere else.
Hermod -----Opprinnelig melding----- Fra: Paul Smith [mailto:[EMAIL PROTECTED] Sendt: 1. april 2003 08:58 Til: 'Log4J Developers List' Emne: RE: JDBC Appender Joshua Blocks "Effective Java" advocates Composition over inheritence, and I've very much warmed to that approach now, hence my preference. I'd agree that the use of inner classes is maybe not the best. I'd actually meant that they are private static inner classes, used by a lookup via a handle in the configuration, but probably best to have them as they're own factory implementations as Mark suggested. Another way to think of the non-abstract approach is the way the appender gets it's connection could be similar to the way an Appender gets it's Layout, via a configuration item. cheers, Paul > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 1 April 2003 4:34 PM > To: [EMAIL PROTECTED] > Subject: SV: JDBC Appender > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
