2012/6/17 Mark Thomas <ma...@apache.org>: > On 16/06/2012 19:18, Mark Thomas wrote: >> >> >> Konstantin Kolinko <knst.koli...@gmail.com> wrote: >> >>> 2012/6/16 Mark Thomas <ma...@apache.org>: >>>> >>>>> 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: >>>>> http://svn.apache.org/viewvc?view=revision&revision=1137646 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>. http://tomcat.apache.org/tomcat-7.0-doc/config/context.html Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
