tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Ludwig <>
Subject Re: Re: Tomcat 6 unstable
Date Wed, 26 Nov 2008 01:04:27 GMT
Caldarale, Charles R schrieb am 25.11.2008 um 17:00:24 (-0600):
> > From: Michael Ludwig []
> > 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 (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 doesn't mean you're infallible.

    Miles to go ...: 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.
    -- 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 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.


> > 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:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message