Well I never, There's been a lot of talk generated by my innocent proposal of using the Observer pattern, or in more java-esque terms events and listeners to arrive at a compromise in the Connection Recovery War. I'd like to clarify some points raised.
In the first place to address the criticism of any compromise being levelled by Juozas, this was intended not to appeal to one camp or the other, but to be a neutral proposal which would accomodate both modes of use. There is nothing in the addition of an event model that should offend either camp, and properly impelemented users who don't choose to listen for events should not notice any impact on performance. Secondly, to address Craig's opinion that we shoudl abandon connection recovery altogether, I proposed that the existing recovery code be refactored to be usable as a listener in the event model because there *are* some users, and some vocal supporters and I would like to think that this community is not so arrogant that we would remove support for them without phaseing it out gradually. The listener implementing connection recovery could be immediately deprecated with text to explain why we don't like it, and scheduled for removal at the next release, giving people time to make other arrangements (probably just fork it :) . Third there are *way* more uses for this than for supporting the forceable recovery of connections, for instance this could be used to log and trace pool activity allowing people to attach tools which will help them to improve their code. It really is much more than just a way in which users can avoid the responsibility of handling connections correctly. Finally it allows the DBCP project to have a finite scope. By providing an API for the attachment of additional functionality we would allow DBCP to encapsulate JDBC Connection pooling, the implementation would not be the concern of users nor necessarily of the majority of implementors of listeners. DBCP could move towards maturity and low maintenance without restricting the creation of new behaviours and tools. d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
