(regarding DefaultServlet) >> If it were using the servlet API only, the code were more reusable, >> both inside and outside of Tomcat. There must be specific issue why >> Servlet API is not used there. Is the API lacking? > > In lot of ways. For example, where is the API to create or delete > resources? That is deliberately left as a container implementation detail. >
OK. One way is to use getRealPath() + manipulate files on the file system directly. I agree that using the API (be it DirContext or something else) is a bit more nice. > > The jndi layer has caused performance problems as well. The special > handling for JARs is a direct result of that. The new approach will > simplify a lot of that and hopefully improve performance as well. Like > we have with the current approach, if there are specific areas causing > problems, we can take a look. I hope and expect that far fewer of these > 'tweaks' would be required with the new implementation. > >>>> 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. >>> Regarding this caching: 1. Currently calling getInputStream() on a jndi URL may return resource directly from memory (cached by ProxyDirContext). If a file URL is used that would involve direct reading from hard drive. If a jar URL is used - I wonder whether opening of the JAR file by the system had to be performed regardless of independent access to the same file. One may argue though that there is ServletContext.getResourceAsStream() method available. 2. If I query some attributes of the resource via getResource().openConnection().getHeaderField(), for jndi URLs they are returned from a cache. I wonder what performance will be there with file and jar URLs. > > I can put a patch of the changes so far on people.a.o if you are > interested (note: it won't compile yet). > I would like to look and review. I think that at the current point this refactoring should not be done directly on trunk without some review and consensus first. Maybe create a branch for this work (create a "tomcat/branches/" directory, or use existing "tomcat/sandbox")? Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
