Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: error (nike.apache.org: local policy)
Message-ID: <52333C11.3000207@christopherschultz.net>
Date: Fri, 13 Sep 2013 12:23:45 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Problem with o.a.c.webresources and packed WARs
References: <52331014.3010005@apache.org>
In-Reply-To: <52331014.3010005@apache.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="gW0gOo47STQjCrMDw708r7sN4lSCoAFmV"

--gW0gOo47STQjCrMDw708r7sN4lSCoAFmV
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Mark,

On 9/13/13 9:16 AM, Mark Thomas wrote:
> The Javadoc for ServletContext#getResource() [3] is clear. The containe=
r
> must provide a URL for every resource and that URL must be usable.

Usable by whom? (Sounds like a dumb question, but please see below)

> There
> is an immediate issue with resources located inside the
> META-INF/resources directory of a JAR which is itself located inside a
> WAR when unpacking WARs is disabled. There is no support from the JRE
> for accessing those resources with a URL.

If the JRE does not support this, then I don't believe it's possible to
return a URL to the caller that is "usable" unless the URL is
accompanied by a URL handler that Tomcat also provides. If the URL must
be universally applicable (e.g. works outside of Tomcat, works with
custom URL handlers that subvert Tomcat's hooks, etc.), then I believe
this is an impossible situation.

> I see three possible solutions to this:
> a) Unpack JAR resources to the work dir and return a URL to the unpacke=
d
> location

-1 due to security considerations plus it really should be possible to
run without expanding WAR files.

> b) Restore something like the jndi url scheme (renamed to tomcat to
> reduce the likelihood of clashes)

You could use any kind of URL scheme, right? There's no reason that the
scheme needs to be conflated with JNDI -- unless there is something that
makes the combination of the two advantageous.

> c) Create a war url scheme only for accessing resources inside WARs

I kind of like this: it just seems like architecturally the right
decision (the problem is the URL, so fix the URL/handler instead of
writing a whole new subsystem to get around it). Plus, it's going to be
much less work and will probably handle all the currently-desired cases.
If it doesn't stand the test of time, you can always invest the time in
re-writing a whole bunch of stuff.

> In trying to decide between b) and c) I came to the conclusion that it
> would be better to keep the war:// url scheme and generic tomcat:// url=

> schemes separated even if we went for option b). Therefore, I intend to=

> go ahead with implementing c) and keep an eye on the users and dev list=

> to see if a case for implementing b) emerges.

+1

-chris


--gW0gOo47STQjCrMDw708r7sN4lSCoAFmV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSMzwRAAoJEBzwKT+lPKRYTxAP/An1VhjGQCDNaOrhlwu++1mN
UdIwcampL+bBM7ylQr/qQsWEOsLpW1LsE/w8bp60on+w0AtPmDVsvBEaVNr6ZY1S
8fnf1P+csw38YLsBv8hDom/Z8YWYExHKa0qPbu4ieVaQUSQ9hRPvI0/Rl+ITEYB3
gLTmz9uH4NpUD0ynDiOQMvRGyQqbJtmOlcBnFSENFsTUd6pNZfauYtCc8e7GfO0Q
OoPgYxw287pofovBYdfQAJ34Hl6msFW3ojMxAeVUA+FpQhQcItrxJ/TSYRBECYk3
UixGYmSqyOYD3+0XsOPldyl7SLyTEp11VCE1tteX1YcSlw5QaFELBWp+Vaw5J6+V
x7EMftgu3bMtDhHW9BVo+Xqfn1Y+CYqeYvTMD+RxIyge3QH0RyPG7SfZJkaj+D3X
eZYBKKbCqgWLnB/I6jjzZknc6ARzylEeO+7wntq4pRe0mqii7eAfp+8jQ2szy/XF
kITJELVsOYQwDz7O63PfnWJWT4PZOMZ7xrjkHGN9rifofMvXsGrx+D2G7oYjNvDb
WQDBi64LYYXYCJllQyqX1Lq2Zjw9IsTQ18FVkgRaZMw27OMksCS58x6UdlYw3DEY
XB/TzKZsHnIKfN+Rk/8M75NtgKy4xSdwbjfnMTf2Gr2uejOMlcNxMX7FvvqnsC01
/yJr1NjfTkr4wEYJgaJW
=kSNn
-----END PGP SIGNATURE-----

--gW0gOo47STQjCrMDw708r7sN4lSCoAFmV--