tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Bergsten <>
Subject Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core
Date Fri, 15 Oct 1999 02:31:37 GMT
"Craig R. McClanahan" wrote:
> Hans Bergsten wrote:
> > [...]
> > But this is a slightly different situation. The intention with all of this
> > was to make Jasper portable between servlet containers. The context attributes
> > are used to let the container inform Jasper about the classpath and class loader
> > that should be used. And any servlet container should be able to do this, not
> > just Tomcat.
> >
> If this is something that all JSP engine implementations need, it should be in the
> public API -- perhaps in some sort of service provider interface.  I think this was
> Jason's original point.

It is, to let the servlet container provide a special class loader and classpath
to be used by the JSP engine (as well as an SSI engine). I agree it should be in the
API and I have had (a long ;-) discussion about this with Duncan, but there wasn't
time to get it into 2.2.

> If this is something that is needed by the Tomcat (no longer Jasper, right?) JSP
> engine, no matter which servlet engine it runs on, I think we should just bite the
> bullet and make it a normal context attribute, visible with getAN() and settable
> with setAN().  Doing what the code does now is an implicit admission that the
> standard public interface is insufficient, and requires other servlet container
> vendors to read the Jakarta source code to see what is "really" needed.  I may be
> overly sensitive on this point, but this is probably one of the reasons I could
> never get the JSWDK JSP engine to run under my 2.1 implementation, and reading the
> source code wasn't an option then.

Since we can't get it into the API right now, I agree that this is the best we
can do today.

> If this is something optimized that the Tomcat JSP engine can take advantage of
> when running under the Tomcat servlet container but there is some "usual" mechanism
> that works everywhere else (Anil mentioned that the fallback was to check for an
> initialization parameter?) then the approach I recommended seems reasonable.

It's not a Tomcat optimization.

Hans Bergsten
Gefion Software

View raw message