On 30/07/2012 15:48, Konstantin Kolinko wrote: > 2012/7/30 Mark Thomas <ma...@apache.org>: >> 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. >> > > I am just saying that it is feels unfair.
It is no better or worse than the current approach in that respect. > 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. > Well, bypassing > the API we can get hands on simpler objects and waste less time > processing them. There is some of that, but a lot of it is functionality that we have to implement. > If it is not a replacement for the current implementation, it might be > a new sample servlet for the examples webapp. > >>> 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. >> > > Others will use Servlet API, and dropping performance is a bad option. 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. >> >>> 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() >> > > It is an existing feature. Removing a feature is bad and needs a good reason. The good reason is cleaning up the code, making the 'overlay' feature in Servlet 3.1 possible. You only have to look at the catalogue of problems the VirtualClassLoader and VirtualDirContext have introduced to imagine how difficult it would be to implement 'overlays' with the current code base. The refactoring makes things a lot, lot cleaner. > BTW, it you wanna take a look at a use case of it, I noticed one place > yesterday. That code is a direct result of a jndi URL being returned. No jndi URLs, no need for that code. The ContextConfig is one of the few parts of the code base I still need to refactor. The other part that is left is the Mapper. The rest is complete but untested. I'd like to have something that at least passes the TCK before committing it. I can put a patch of the changes so far on people.a.o if you are interested (note: it won't compile yet). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
