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 Sun, 30 Jul 2000 23:28:28 GMT
Remy Maucherat wrote:

> > Agree that these should not go into Resources interface, at least for now.
>
> Ok.
>
> > 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)
>
> I don't know anything about Jasper, so well ...
>

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.

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

>
> > > - 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
> 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%.
>
> 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 :-)
>

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

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

>
> I guess after all those changes are made, I'll have to do another rounds of
> benchmarks :-)

Should be interesting :-)

>
> Remy

Craig

Mime
View raw message