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
signature.asc
Description: OpenPGP digital signature
