tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: [Proposal] Preparatory refactoring for Resource handling refactoring
Date Mon, 30 Jul 2012 00:16:19 GMT
2012/6/17 Mark Thomas <>:
> On 16/06/2012 19:18, Mark Thomas wrote:
>> Konstantin Kolinko <> wrote:
>>> 2012/6/16 Mark Thomas <>:
>>>>> URLs are needed per Servlet API, so they cannot be removed.
>>>>> Does our "jndi" schema need DirContext as underlying
>>>>> implementation?
>>>> Our jndi scheme was used to provide access to resources. I
>>>> believe
>>> all
>>>> of that will now go.
>>>>> I noticed the following commit in archives:
>>>>> so
>>>>> we have to deal with such schema combinations as "jar:jndi:".
>>>> No we won't. We only hadf to deal with URLs like that because we
>>>> generated them.
>>> How are you going to implement ServletContext.getResource(String):
>>> URL
>>> without a custom URL scheme  (be it named "jndi" or somehow else)?
>>> For file resources it might be possible to produce the "actual"
>>> URL pointing to a JAR entry or to a file (leaving aside the
>>> question of whether it exposes too much details),  but you cannot
>>> do so with directories,  as entries in a directory can be assembled
>>> from several sources.
>> My intention was to use the URL for the actual resource. For
>> directories, I'll use the first matching dir I find although I need
>> to re-read the spec and Javadoc to make sure there aren't any nasty
>> surprises waiting to trip me up.
> Having re-read the specification and Javadoc, I don't see anything of
> concern. Additional pairs of eyes wouldn't hurt though.
> How to handle getResource() for a directory that exists in one or more
> overlays and/or the main WAR is an interesting question. I'll be sure to
> raise it within the Servlet EG when we get back to that question.

If we remove JNDI stuff from resource handling,  one of "challenges"
might be to re-implement DefaultServlet using only Servlet API
methods. Well, if the former is not possible, it might use the new
resources API (that you are going to implement instead of jndi one)
and be thus still tied with Tomcat internals...

If one reimplements DefaultServlet, one of the tasks would be to
generate directory listings. Those include file size and file
timestamp. One needs to obtain URL of a resource, open its
URLConnection and ask those attributes.

One good thing with "jndi:" URLs returned via Servlet API is that they
are backed by an instance of ProxyDirContext class and it has a cache
(*).  If we change implementation and return "true" URLs, they will
bypass the cache.  I suspect that using a "jar:" URL directly (in case
of an unpacked WAR file) may have poor performance.

Other good thing is that you can create relative URLs as "new URL(Url,
String)", which inherits URLStreamHandler instance from the original
URL, and thus inherits access to ProxyDirContext instance.  If it is a
"jndi" URL it will have access to the full resources hierarchy of the
web application.  If it is a "true" URL, it will be limited to its
origin file system.

The above two are the reasons why I think that in Tomcat 8 we cannot
return "true" URLs from ServletContext.getResource(String) method and
must still support the "jndi:" or some other proprietary URL schema.

(*) for reference: TTL of entries in ProxyDirContext#cache is by
default 5 seconds (5000). If the time has elapsed, the resource is
revalidated by comparing its timestamp with original one  The TTL is
configured via ProxyDirContext constructor <- BaseDirContext#cacheTTL
<- StandardContext#cacheTTL and thus is configurable on a <Context>.

Best regards,
Konstantin Kolinko

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message