tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <r...@apache.org>
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
JavaMail,
> > 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
hair-brained)
> 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
the
> resources available to a web application?  The idea would be to use
directory
> 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
servlet
> 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
factory.ResourceFactory.
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 ?

Remy


Mime
View raw message