tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <>
Subject Re: [TC4] ResourcesBase.setCheckInterval() (not a) bug
Date Fri, 17 Nov 2000 03:01:18 GMT
> > BTW: I really like the resources package!  I can think of several useful
> > implementations that I'd like to use, like one for CVS, or one for
> > or ...  lots more.
> I like the Resources abstraction as well.  Before we go whole hog at
creating new
> implementations, though, I'd like us to consider one (possibly
> idea.
> The major purpose for creating the Resources abstraction in the first
place was
> to hide the distinctions about *how* resources were accessed from the rest
of the
> servlet container.  The Resources interface (as extended by Remy to
support what
> WebDAV needs) does this, but is not the only way to accomplish it.
> What would you think about using a JNDI DirContext as a representation of
> resources available to a web application?  The idea would be to use
> entry attributes for the commonly used information like "last modified
date" and
> "number of bytes in this resource", rather than Java properties.  We'd
want to
> standardize on attribute names to be used (perhaps starting from the File
> directory context already available with JNDI) so that the rest of the
> container can access them.  Obviously, this would be a per-webapp
structure, just
> like the naming context for <env-entry> and <resource-entry> things is.
In fact
> ... maybe it could even be a subcontext of that very same context ...
> What do you think?

Here's what I'll do.
I'll add an org.apache.naming.resource.FileDirContext class, which will be
an implementation of javax.naming.DirContext. It will be built by the
The Resource will be declared in the web app descriptor as a resource-ref
element. Additional parameters (path, ...) will be specified there too.
The factory will actually return an
org.apache.naming.resource.CacheDirContext which wraps the real DirContext
to provide transparent caching.
The resources will be availible through the usual java:/xxxx URL.

Questions :
- Do we keep the current Resources ?
- Isn't it a bit late in the release process to do that big change ? I can
do the FileDirContext and CacheDirContext, and test them with a few
servlets, no problem, but I'm thinking about rewriting DefaultServlet and
WebdavServlet (ouch, that hurts ...). Can we do that for 4.1 ?


View raw message