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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
