IMO, a design that allows users to plugin behaviors, be they connection retrieval or otherwise, is the best solution. Then the question becomes whether to include a connection retrieval behavior in the DBCP release. I think that's far outside the scope of DBCP and encourages users to rely on Jakarta code to fix their apps. That is a poor precedent to set.
I'm not sure what you mean... supporting abandoned code will not fix code, and having Jakarta code fix (and encourage better design and keep people from writing their own bad implementations to common problems) are all great precedents.
There is _no_ abandoned code approach that will fix code. Waiting for a finalizer to return a database collection will never result in an application behaving well. The issue is having more control over what happens in this situation, such as preventing a rarely called piece of code from failing quickly (will fail slowly, ideally allowing you tolerate it until fix in an upcoming release).
I mean, c'mon, some apache developers are so full of themselves, I think they would welcome the opportunity to correct others code. :)
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
