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.
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? Well, bypassing
the API we can get hands on simpler objects and waste less time
processing them.
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.
>> 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.
BTW, it you wanna take a look at a use case of it, I noticed one place
yesterday.
In ContextConfig.processAnnotationsJndi(...) there is code
[[[
Enumeration<String> dirs = dcUrlConn.list();
while (dirs.hasMoreElements()) {
String dir = dirs.nextElement();
URL dirUrl = new URL(url.toString() + '/' + dir);
processAnnotationsJndi(dirUrl, fragment, handlesTypesOnly);
}
]]]
It creates a relative URL there.
If it were using the constructor for relative URLs, new URL(url,
dir), it would have better performance, because URLStreamHandler were
inherited from the old URL. A question that needs testing before
making a change there, though, is whether the old URL ends with "/"
(and thus is a directory). The code behaves as if it did not have the
trailing "/".
>> 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.
>
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
