Caldarale, Charles R schrieb am 25.11.2008 um 17:00:24 (-0600):
> > From: Michael Ludwig [mailto:[EMAIL PROTECTED]
> > 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
