tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: [TC4] ResourcesBase.setCheckInterval() (not a) bug
Date Fri, 17 Nov 2000 03:35:14 GMT
Remy Maucherat wrote:

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

I agree with looking at a change in resources implementation in a 4.1
timeframe.  Looking back, I sure didn't make that clear.

In the mean time, let's continue to focus on bug fixes and performance for 4.0.

>
> Remy

Craig



Mime
View raw message