Good point if you want to share it. But then why does the server.xml allow you to configure JNDI datasources for a web application or globally?
----- Original Message ----- From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Friday, February 14, 2003 11:06 PM Subject: Re: [dbcp] DBCP classloader in Tomcat 4.1.18 > > > On Fri, 14 Feb 2003, Christopher M. Judd wrote: > > > Date: Fri, 14 Feb 2003 22:56:15 -0500 > > From: Christopher M. Judd <[EMAIL PROTECTED]> > > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > > To: Jakarta Commons <[EMAIL PROTECTED]> > > Subject: [dbcp] DBCP classloader in Tomcat 4.1.18 > > > > I am building a web application using Tomcat 4.1.18, Struts 1.1 b3 and > > MSSQL. I have used Struts 1.0 in the past and configured the datasources > > in struts-config.xml file. This is my first attempt at using Struts 1.1 > > b3 and datasource configurations in the struts-config.xml file have been > > deprecated. I tried to configure the datasource using JNDI several times > > with no luck. I repeatedly got ClassNotFoundExceptions on the MSSQL > > driver class. I tried placing the MSSQL jars in the WEB-INF/lib of my > > web app, in the server/lib and in the shared/lib. Finally I tried > > creating a JSP and doing a Class.forName(). The JSP could find the class > > so I realized after many hours of trial and error it must be a > > Classloader issue. I finally found the common/lib directory and that > > worked. After thinking about it I realize the issue and that the > > common/lib jars must be in a different Classloader. However, I am > > wondering if there is an issue with the way commons-dbcp locates and > > loads classes. Requiring database jars to reside in the common/lib and > > not in the web applications WEB-INF/lib reduces flexibility. > > > > What happens if the data source (connection pool) you are configuring is > shared between webapps? That's going to cause a pretty significant > problem. > > If you are using JNDI-based resources, you are saying (in effect) that it > is the container's responsibility to provide you with that object, > completely configured and ready for use by a webapp. Therefore, it > doesn't make sense to include any of the classes in your webapp itself -- > instead, you need to make them part of the container (Tomcat in this case) > configuration. > > Craig > > > --------------------------------------------------------------------- > 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]
