Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 85949 invoked from network); 26 Nov 2008 01:06:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Nov 2008 01:06:22 -0000 Received: (qmail 70520 invoked by uid 500); 26 Nov 2008 01:06:21 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 70489 invoked by uid 500); 26 Nov 2008 01:06:20 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 70478 invoked by uid 99); 26 Nov 2008 01:06:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Nov 2008 17:06:20 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of milu71@gmx.de designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 26 Nov 2008 01:04:52 +0000 Received: (qmail invoked by alias); 26 Nov 2008 01:04:35 -0000 Received: from unknown (EHLO wladimir) [78.52.53.124] by mail.gmx.net (mp027) with SMTP; 26 Nov 2008 02:04:35 +0100 X-Authenticated: #48488578 X-Provags-ID: V01U2FsdGVkX18gyUMgHm8gGXsKgTJanKSgxVOd+6h1AVlVM1/H5m +L5ABDtqZGwRdI Received: by wladimir (sSMTP sendmail emulation); Wed, 26 Nov 2008 02:04:27 +0000 Date: Wed, 26 Nov 2008 02:04:27 +0100 From: Michael Ludwig To: Tomcat Users List Subject: Re: Re: Tomcat 6 unstable Message-ID: <20081126010427.GE3672@wladimir> References: <885592.76005.qm@web52807.mail.re2.yahoo.com> <20081125025024.GQ1112@wladimir> <0AAE5AB84B013E45A7B61CB66943C17215A3D3548F@USEA-EXCH7.na.uis.unisys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <0AAE5AB84B013E45A7B61CB66943C17215A3D3548F@USEA-EXCH7.na.uis.unisys.com> User-Agent: Mutt/1.4.2.2i X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 X-Virus-Checked: Checked by ClamAV on apache.org Caldarale, Charles R schrieb am 25.11.2008 um 17:00:24 (-0600): > > From: Michael Ludwig [mailto:milu71@gmx.de] > > Subject: Re: Re: Tomcat 6 unstable > > > > I've read somewhere that omitting the file:/// URI scheme is wrong. > > However, it seems to work. At least on Windows. In order to be on > > the safe side, you should add the "file:///" URI scheme. > > No, you shouldn't. (Note that the existing settings do not use it.) My copy of catalina.properties (Tomcat 6.0.18) contains the following instruction for modification of the "shared.loader": Please note that for single jars, e.g. bar.jar, you need the URL form starting with file:. Anyway, sorry if I've spread misleading information. I had picked this usage of not only plain "file:", but full-blown "file://" up somewhere and, lack of prior experience, given it credence. I see it used in some places, but of course, just because you're blogging on Java from underneath SUN.com doesn't mean you're infallible. Miles to go ...: Metro on Tomcat 6.x http://blogs.sun.com/arungupta/entry/metro_on_tomcat_6_x > Such a reference turns the local file request into a network one > rather than a direct reference to the local file system. The empty > host name (between the second and third slashes) indicates the file > should be served by localhost I don't think the file URI scheme without a hostname translates into a network request. For what would be the protocol used for such a request? > and the JRE may be smart enough to short-ciruit the network Hopefully! This is very vague anyway, and admittedly so: The file URL scheme is unusual in that it does not specify an Internet protocol or access method for such files; as such, its utility in network protocols between hosts is limited. -- http://www.rfc-editor.org/rfc/rfc1738.txt 3.10 FILES > but regardless, you're adding unnecessary overhead. I agree. There are (XML) technologies which are designed to be filesystem-agnostic, and these may require you to use a file URI instead of a good old pathname, so I may well have been misled. > In any event, you shouldn't be modifying the classloader settings > without an extremely good reason. I believe you. But catalina.properties does not contain any admonitions to that effect. On the contrary, it contains instructions on how to proceed in order to modify the classloader settings. > > If your connection is closed, either explicitly or implicitly > > by going out of scope, all objects derived from it are also > > closed. > > Connections do not close when they go out of scope. They *may* get > closed when a garbage collection occurs, but you should never write > code that depends on that happening (it may never happen). True - I should have known better. > It is absolutely critical to explicitly close result sets, statements, > and connections; this is best done by placing all data base access > inside try/finally blocks and doing the close operations in the > finally part. Yes. > > The whole point of the pool, however, is to *not* close the > > connection. > > Correct. But what the pool gives you is a wrapper for the actual > connection object, and failing to close that means it doesn't get back > into the pool, resulting in an empty one after a bit. True - I should have been more explicit. You should be tidy and close all your database objects *including* the connection. Thanks for all clarifications and corrections. Michael Ludwig --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org