This is issue e) in Konstantin's comments in TOMCAT-NEXT.txt Copying Konstantin's notes:
Goodies: - Uniform URL space. Both files and directories can be represented, hiding details of aliases, resource jars, etc. - It hides implementation details. - Permissions can be expressed as JndiPermission. They do not depend on context version number. - Accessing a resource through such URL leverages the cache implemented in ProxyDirContext class. We do not access the file system directly, nor need to open a JAR file. - It can be created from a String if necessary. Such use relies on DirContextURLStreamHandler.bindThread(..) being called earlier in the same thread. Concerns: - Some components would like to get "real" resource URL from this one. Maybe it can be exposed through some special header name, DirContextURLConnection.getHeaderField(str)? How such real URL can be prepared? DirContext.getNameInNamespace()? BaseDirContext.getRealPath()? ((FileResourceAttributes)DirContext.getAttributes()).getCanonicalPath()? - A resource lookup is performed twice. The first time in ServletContext.getResource() (implemented in ApplicationContext.getResource()) to return null for non-existing paths. The second time in DirContextURLConnection.connect(). It is good that there is a cache in ProxyDirContext that saves time for repeated lookups. - Using URLs involves encoding/decoding. If there were some other API to access resources in a web application, I would prefer some opaque object that allows access to resource properties, but is converted to string/url form only on demand. I think this boils down to "Is there a requirement for a scheme that provides unified URLs?" While it does hide the details of where stuff is from an application, if does so with a layer of indirection and that has a performance cost. Note: Performance / caching is a separate issue and I have already created a separate thread for that. If this feature is required, it can be added by modifying / wrapping the StandardRoot implementation. Currently, I think the only reason we might need this is if we need caching for performance then we'll need a custom URL scheme to ensure access via URLs goes through the cache. Therefore, in my view, resolving this issue depends on determining if caching (in a similar manner to the current implementation) is required. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org