tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Problem with o.a.c.webresources and packed WARs
Date Fri, 13 Sep 2013 16:23:45 GMT
Mark,

On 9/13/13 9:16 AM, Mark Thomas wrote:
> The Javadoc for ServletContext#getResource() [3] is clear. The container
> 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 unpacked
> 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


Mime
View raw message