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
