tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <>
Subject Re: [Catalina] Resources
Date Sun, 30 Jul 2000 06:20:14 GMT
> 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
> 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
> -- JSPs won't work yet due to Jasper restrictions)

I don't know anything about Jasper, so well ...

> 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
> 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'll modify DefaultServlet to use Resources (while leaving in the old
> > code, just in case).
> >
> +1.
> PS:  Sorry for meddling in org.apache.tomcat.connector at the same time
> 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%.

It seems the merge was successful. Basically, I was toying with Slide and
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 :-)

> PPS: One of the areas of performance improvement I want to play with a
> at some point is the parsing speed inside HttpProcessor.  Right now it
> StringTokenizer and some other stuff that is pretty expensive -- I want to
> 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
> code uses instance variables in the underlying class to save state).

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


View raw message