Resources - Custom URL scheme for unified access

[Mark Thomas <ma...@apache.org>]

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Resources - Custom URL scheme for unified access

[Remy Maucherat <re...@apache.org>]

On Tue, 2012-10-09 at 22:19 +0100, Mark Thomas wrote:
> If we do go this route I'd like to change the scheme from "jndi://" to
> "tomcat://". This is for several reasons:
> - I believe there was a complaint that "jndi://" clashed with another
>   component.
> - It makes clear the old and the new are very different and not
>   compatible.

Not sure if it clashed with something, but the main reason it was
"jndi://" is because the API used was JNDI. So use something else,
"tomcat://" sounds good.

Rémy



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Resources - Custom URL scheme for unified access

[Mark Thomas <ma...@apache.org>]

On 09/09/2012 20:13, Mark Thomas wrote:
> This is issue e) in Konstantin's comments in TOMCAT-NEXT.txt

<snip />

> 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.

Aside: I haven't looked at what the overhead for implementing this might
be yet.

> 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.

Caching is definitely required. So, do we need to provide a custom URL
scheme?

Pros:
- Apps that use URLs would benefit from the cache

Neutral
- Hides real location and type of resource

Cons:
- Overhead
- URLs require encoding / decoding

If we do go this route I'd like to change the scheme from "jndi://" to
"tomcat://". This is for several reasons:
- I believe there was a complaint that "jndi://" clashed with another
  component.
- It makes clear the old and the new are very different and not
  compatible.


I'm very much on the fence at the moment as I don't have any hard
evidence for either the costs or the benefits of implementing this. I'm
leaning towards leaving this as a TBD, putting out an early milestone /
release candidate and getting some user feedback on performance.

Thoughts?

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org