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

Reply via email to