tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <>
Subject Re: [Catalina] Resources
Date Mon, 31 Jul 2000 16:45:22 GMT
> Currently, Jasper uses native file I/O to do it's "last modified" check
> of the
> JSP page source file.  Therefore, I would not expect it to work when
> trying to
> run using JarResources instead of FileResources.

java.lang.IllegalArgumentException: Context relative path
\jsp\dates\date.jsp must start with /

I guess the validate method has to be made more tolerant ...

> > > OK, I'm +1 for this.  The
> > > context config class (org.apache.tomcat.startup.ContextConfig also
> > to be
> > > modified to select the correct Resources implementation if one hasn't
> > already
> > > been installed.  (Right now it defaults to StandardResources).
> >
> > I replaced that with FileResources.
> > I don't know what you mean by "selecting the right Resources". How will
> > be done ?
> >
> I'm envisioning an addition to ContextConfig that does this, similar to
> the way
> that it picks the right Authenticator based on which login method you
> want.  The
> way that process works is like this:
> * ContextConfig is added as a LifecycleListener to the Context
>   when it is created, so it finds out about start() and stop() events
>   sent to the Context.
> * During processing of the start() event, it calls the
>   authenticatorConfig() method which looks at your web.xml
>   settings and installs the right kind of Valve.
> Right now, ContextConfig.start() includes the following code:
>     if (context.getResources() == null) {
>         ... log debug message ...
>         context.setResources(new StandardResources));
>     }
> which hard codes the StandardResources implementation if the sysadmin
> did not

Now, it's FileResources :-)

> configure one explicitly in server.xml.  If we made this logic a little
> smarter,
> it could call context.getDocBase() and examine the result.  A simple
> rule (until
> we have more than two kinds) would be to say if the docBase string
> starts with
> "jar:", install a JarResources instance; otherwise install a
> FileResources
> instance.  Later on, if we had other standard choices available, we'd
> just make
> the if statement a little smarter.

Ok, but we can only be smart for implementations we already know (file, jar,
...). That was my point.

> > > > - I'll modify DefaultServlet to use Resources (while leaving in the
> > > > code, just in case).
> > > >
> > >
> > > +1.
> > >
> > > PS:  Sorry for meddling in org.apache.tomcat.connector at the same
> > you
> > > were -- I was going through all the packages doing the changes for
> > > collections.  The change I checked in incorporated the fix you posted,
> > > everything should be up to date.  Still passes Watchdog 100%.
> >
> > It seems the merge was successful. Basically, I was toying with Slide
> > found that bug. At first, I was all worried since my attempts to use PUT
> > with large entities were failing with out of bounds exceptions :-)
> >
> One thing that is puzzling me a little, though ... why do you need
> access to the
> DirectoryBean object in DefaultServlet?  If you ask for
> getResourceAsStream() on
> a resource path that is a directory, it's going to give you back the
> expanded
> text of that directory already (or a null if you've configured it not to
> expand
> directory listings).

And if you look at my implementation, you'll notice that indeed I'm not
using it (and the getResourceBean method I planned to add is commented out.
Basically, I read the code a bit too quickly.
BTW, I struggled a bit to make the directory browser work, as I had a lot of
path related problems.

> > I saw the new class. I planned to reuse some of the Tomcat header
> > functions, but I never had time to rewrite that part (the
StringTokenizer is
> > the biggest problem right now, IMO; for example, IE includes the
> > header in each request, so this part of the code is actually used most
> > the time ;-) ).
> Yah, parsing Accept-Language is a little more intricate, so I only used
> the new
> class for the request line itself at the moment.
> >
> > I guess after all those changes are made, I'll have to do another rounds
> > benchmarks :-)
> Should be interesting :-)

Of course, the biggest gain would probably come if we started using some
buffer operations (arraycopy ...) to do most string operations.

The benchmarks right now are not that great for static files, because a lot
of operations are uncached, like the calls to File.length() and

The servlets benchs went down a bit lately (around 5% overall). The
benchmark I use doesn't use the "language" header, so there was no
improvements because of that, but I'm sure the real world performance went
up quite a bit.

>   * Leave out any entries for WEB-INF and META-INF (trying to follow the
>     links would fail anyway, so there is no reason to show them)

Actually, that was working, but I think it's a security problem to display

I found a problem with the rewriting of some characters in the URL. "%20" is
no longer converted into " " (I think it was working at one point, but I
can't really remember. I added that in ResourcesBase.normalize. Do you think
it's the right place for that ?
If you're +1, I'm committing the (very small) fix.

I'll work on the WebDAV servlet for the immediate future.
Propfind is already done, so you can browse the site using Webfolders.


View raw message