tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [Catalina] Resources
Date Mon, 31 Jul 2000 18:54:21 GMT
Remy Maucherat wrote:

> > 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 /
>  at
> org.apache.tomcat.resources.ResourcesBase.validate(
>  at
> org.apache.tomcat.resources.FileResources.getRealPath(
> )
>  at
> org.apache.tomcat.core.ApplicationContext.getRealPath(ApplicationContext.jav
> a:333)
>  at
> org.apache.jasper.JspEngineContext.getRealPath(
> <snip/>
> I guess the validate method has to be made more tolerant ...

I'm OK with translating "\" to "/", I guess, but it should be done
and very early in each of the spots validate() is already called --

    path = normalize(path);

and the "normalize" method can do this change if it needs to.


> > > > OK, I'm +1 for this.  The
> > > > context config class (org.apache.tomcat.startup.ContextConfig also
> needs
> > > 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
> it
> > > 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.

True ... but we can embed smartness in a properties file where the key
is the
URL scheme and the value is class name to use; basically the way
are looked up based on login method.  That way, people using Catalina
can add
custom extensions to the list of supported resource bases by defining
their own
URL scheme prefixes -- which they are going to have to do anyway to
something useful from getResource() -- and add a mapping to a property
file with
no changes to the code of ContextConfig.

The default should be to use FileResources if we can't figure out
else.  That covers the case where a relative or absolute pathname is
without the "file:" prefix.

> [snip]
> >
> > 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.

Let's go ahead and remove the code we don't need (including the unused
now that it is clear the code will not be required.

> 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
> parsing
> > > functions, but I never had time to rewrite that part (the
> StringTokenizer is
> > > the biggest problem right now, IMO; for example, IE includes the
> "language"
> > > header in each request, so this part of the code is actually used most
> of
> > > 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.

As you probably saw, I added another patch that improves the speed of
parsing when it is done -- avoids StringTokenizer, and uses
access to collection classes (because this is all local variables so
there is no
opportunity for multi thread access to cause problems).

> >
> > >
> > > I guess after all those changes are made, I'll have to do another rounds
> of
> > > 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.

Yep, as long as we're talking byte arrays.  Once you start talking about
Strings, we have to deal with the i18n issues, which (as Costin can
attest to
:-) get pretty sticky.

> 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
> File.lastModified().

I thought about that one quite a bit.  Basically, we have to decide
whether we
want the user to be able to modify files in the docBase directory, and
those changes recognized even when the old version was cached.  The way
detect changes seems to be to flow through the cache for the "last
check (although you can probably use any cached value for the file
length safely
-- modifying this will have set the last modified date anyway).

For JarResources, I explicitly assumed (as stated in the class comments
in the
Javadoc) that you won't be trying to modify the JAR file while the app
running -- if you want to change things, you need to restart the app. 
why it pre-caches all the file and directory entries out of the JAR, and
caches the data according to the cacheable() policy.

> 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
> them.

Yep ... they no longer display.  I also cleaned up a few other details
weren't quite right in the rendered HTML.

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

+1 to fix (i.e. URL encode) the hyperlink that is part of the "<a
element.  The displayed filename should still have the spaces in it.

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


> Remy


View raw message