On Wed, 2006-09-13 at 15:07 +0200, Remy Maucherat wrote: > > The resultant package is significantly smaller, and there's no chance of > version conflict if the user wants to put a different version of DBCP in > the shared folder.
Ok that makes sense. Thanks for the info. Any chance of Tomcat making it's own implementation? Even less chance of a version conflict then ;) Although it does not seem like Tomcat uses that jar. So if there was a version conflict, the user could remedy by removing one or the other of the conflicting dbcp jars. Basically the main problem on Gentoo is we don't want to have to pull in sources for 3 other commons apps in conjunction with Tomcat's sources just to build the naming-factory-dbcp.jar. Despite it looking like that's the only way. Otherwise we have to do some craziness just to build that one jar. Which for the end user I am not sure as to the benefit? Other than size or version conflict avoidance. In the mean time we are building Tomcat less that one jar. For those that must use Tomcat's naming factory, we have them fetch the jar from a binary copy of Tomcat. Otherwise they can use commons naming factory. Or since it most always pertains to JDBC usage, the naming factory in their JDBC driver. Are there any performance benefits or etc? What about bugs or etc if a bug is detected in commons-dbcp how does that get addressed in Tomcat? Any major hangups or reasons for Tomcat to not have it's own implementation? Aside from reuse of existing code and etc. Thanks -- William L. Thomson Jr. Gentoo/Java
signature.asc
Description: This is a digitally signed message part
