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: [Catalina] Resources
Date Sat, 29 Jul 2000 22:43:59 GMT
Remy Maucherat wrote:

> Hi Craig,
>
> The move to Resources is going smoothly. It should be done later today if I
> can solve some issues.
>
> - The directory browse (and others) are generated by the DirectoryBean.
> That's fine, but there is no way to access either ResourceBean or
> DirectoryBean from outside ResourcesBase, so we should add the following
> function to ResourcesBase :
> ResourceBean getResourceBean(String path) or something like that. It's
> probably not a good idea to add it to the Resources interface (to avoid
> creating a dependency).
> This is needed for DefaultServlet.
>

Agree that these should not go into Resources interface, at least for now.

The DirectoryBean and ResourcesBean classes also need to be made public in that
case - right now they are package private.

>
> - I'll remove StandardResources at the same time. Are you +1 with this ?
>

Once you are satisfied that the new code works (for static files and servlets
-- JSPs won't work yet due to Jasper restrictions) 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'll modify DefaultServlet to use Resources (while leaving in the old
> code, just in case).
>

+1.

>
> Remy
>

Craig

PS:  Sorry for meddling in org.apache.tomcat.connector at the same time you
were -- I was going through all the packages doing the changes for
collections.  The change I checked in incorporated the fix you posted, so
everything should be up to date.  Still passes Watchdog 100%.

PPS: One of the areas of performance improvement I want to play with a little
at some point is the parsing speed inside HttpProcessor.  Right now it uses
StringTokenizer and some other stuff that is pretty expensive -- I want to copy
the basic idea that Costin put into the Tomcat 3.2 connectors (parsing for
"start" and "end" points, then pulling out substrings), but want to do it in a
more general purpose StringParser class so it's reusable, and so that the
connector can parse more than one kind of string if it needs to (the current
code uses instance variables in the underlying class to save state).




Mime
View raw message