tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: Location of third party jar files.
Date Wed, 08 Sep 2004 18:45:07 GMT

Hi,
Under some circumstances, it's preferable to bundle your own pooling
library with your app rather than use the container-provided one.  It's
trivial to drop commons-dbcp.jar (and its one dependency,
commons-pool.jar) into your WAR and configure your own connection
pooling.  

Advantages:
- You deploy in one WAR, same to all containers
- The extra step of copying the JDBC jar to your common/lib directory
(which is of course different on every server implementation) is not
needed
- You don't need to worry about possible bugs in the container's
implementation of connection pooling (history shows these are plentiful
in some containers)
- You don't need to learn each container's syntax for connection pooling
configuration

Disadvantages:
- You need to package a new WAR if the database URL (or user name, or
password) changes.  With container-provided pooling, you can just change
the container's configuration in this case, much easier.

Personally I go package DBCP with my app WARs frequently, because I'm a
big fan of easy portability.  Even though I know Tomcat inside and out
for the most part, I don't want to learn the same connection pooling
configuration stuff for every container I use.  One WAR works
everywhere, it's great.

Yoav Shapira
Millennium Research Informatics


>-----Original Message-----
>From: Jeffrey Barnett [mailto:jeffrey.barnett@yale.edu]
>Sent: Wednesday, September 08, 2004 2:34 PM
>To: Tomcat Users List
>Subject: Re: Location of third party jar files.
>
>That was my point earlier.  Or is there something so inherently wrong
>with using /common/lib that you would forgo the pooling option?
>
>Mike Curwen wrote:
>
>>I believe you'd *need* to put them there (common/lib)
>>if you were using a container-managed connection pool.
>>
>>
>>
>>
>>>-----Original Message-----
>>>From: Jeffrey Barnett [mailto:jeffrey.barnett@yale.edu]
>>>Sent: Wednesday, September 08, 2004 1:18 PM
>>>To: Tomcat Users List
>>>Subject: Re: Location of third party jar files.
>>>
>>>
>>>I believe Yoav said earlier it was OK to put JDBC drivers into
>>>common/lib.  Or did I misunderstand, there was a bit of back
>>>and forth
>>>on the topic.  Search Archives for "Tomcat 4.1: JSP pages
>>>don't always
>>>compile the first time?"
>>>
>>>Shapira, Yoav wrote:
>>>
>>>
>>>
>>>>Hi,
>>>>The right and best way is to include copies of them in your
>>>>
>>>>
>>>WEB-INF/lib
>>>
>>>
>>>>directory.  Don't symlink, don't put them in common/lib or
>>>>
>>>>
>>>shared/lib,
>>>
>>>
>>>>don't put them on the bootstrap classpath.
>>>>
>>>>Yoav Shapira
>>>>Millennium Research Informatics
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Kyle A. Boyd [mailto:kboyd@brit.com]
>>>>>Sent: Wednesday, September 08, 2004 1:19 PM
>>>>>To: tomcat-user@jakarta.apache.org
>>>>>Subject: Location of third party jar files.
>>>>>
>>>>>We are using a couple of third party jar files. I can only get our
>>>>>application to see them if I add them to the tomcat/common/lib/
>>>>>directory. This is inconvenient for our setup. Is there any
>>>>>
>>>>>
>>>other way
>>>
>>>
>>>>>for Tomcat to find the jar files in the classpath (works
>>>>>
>>>>>
>>>with Tomcat
>>>
>>>
>>>>>3.2), a .xml file, or with a symbolic link?
>>>>>
>>>>>We are using Tomcat 5.0.27.
>>>>>
>>>>>Thanks,
>>>>>Kyle
>>>>>
>>>>>
>>>>>------------------------------------------------------------
>>>>>
>>>>>
>>>---------
>>>
>>>
>>>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail:
tomcat-user-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>This e-mail, including any attachments, is a confidential business
>>>>communication, and may contain information that is confidential,
>>>>proprietary and/or privileged.  This e-mail is intended only for the
>>>>individual(s) to whom it is addressed, and may not be saved, copied,
>>>>printed, disclosed or used by anyone else.  If you are not the(an)
>>>>intended recipient, please immediately delete this e-mail from your
>>>>computer system and notify the sender.  Thank you.
>>>>
>>>>
>>>>--------------------------------------------------------------------
-
>>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org




This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message