tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: [Proposal] Preparatory refactoring for Resource handling refactoring
Date Mon, 30 Jul 2012 14:18:18 GMT
On 30/07/2012 01:16, Konstantin Kolinko wrote:
> 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...

This is a non-issue in my view. The current DefaultServlet uses Tomcat
internals extensively. The new implementation will to.

> 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.

Only if doing so entirely via the Servlet API which we don't need to do.

> 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.

The new Resources implementation will include caching where necessary.
At the moment there is none. I intend to add it as required. I agree
JARs/WARs are likely to need it to have performance that is comparable
with expanded WARs.

> 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.

That is true, but why is that necessary? Is it a specification
requirement? I'm not aware of it. The canonical identifier is the path
of the resource within the app, not the URL returned from getResource()

> 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.

I agree that the second issue would require a custom URL scheme if it
were a requirement but I am not aware of anything that states that it is.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message