Return-Path: <Craig.McClanahan@eng.sun.com>
Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list tomcat-dev@jakarta.apache.org
Received: (qmail 72831 invoked from network); 17 Nov 2000 03:33:59 -0000
Received: from lukla.sun.com (192.18.98.31)
  by locus.apache.org with SMTP; 17 Nov 2000 03:33:59 -0000
Received: from centralmail1.Central.Sun.COM ([129.147.62.10])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA28046
	for <tomcat-dev@jakarta.apache.org>; Thu, 16 Nov 2000 20:33:59 -0700 (MST)
Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144])
	by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id
 UAA22110
	for <tomcat-dev@jakarta.apache.org>; Thu, 16 Nov 2000 20:33:58 -0700 (MST)
Received: from eng.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4)
	id UAA25123; Thu, 16 Nov 2000 20:45:52 -0700
Message-ID: <3A14A772.2BEE608C@eng.sun.com>
Date: Thu, 16 Nov 2000 19:35:14 -0800
From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Sony}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: [TC4] ResourcesBase.setCheckInterval() (not a) bug
References: <3A145EA2.5040505@olliance.com>
 <002601c0502c$8e3eb030$82deb018@intalio.com> <3A147F89.1080203@olliance.com>
 <3A148403.6E492BF@eng.sun.com> <008d01c05042$a852b4b0$82deb018@intalio.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

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