tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anil K. Vijendran" <>
Subject Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core
Date Fri, 15 Oct 1999 08:30:40 GMT

"Craig R. McClanahan" wrote:

> > >
> > > You can avoid the whole issue of using context attributes at all if you
> > > modified the JSP engine code to do something like this:
> > >
> > >     String classpath = null;
> > >     ServletContext context = getServletContext();
> > >     if (context instanceof org.apache.tomcat.core.Context) {
> > >         classpath =
> > >           ((org.apache.tomcat.core.Context) context).getClassPath();
> > >     } else {
> > >         classpath = ...;    // Initialized some other way
> > >     }
> > >
> > > With this approach, there are no implementation-specific context attributes
> > > worry about, so there is no reason to hard code mangling into getAttribute()
> > > and getAttributeNames(), and the intent is perfectly clear.

I haven't verified this but wouldn't you get a linker error if for example there's a
class file that contains a reference to org.apache.tomcat.core.Context.class and it is
attempted to be loaded in a servlet container which does not have that class?

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

Bad timing. :-( That's why we can't get it into 2.2, I hear.

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

Actually, there is a reasonable default there... like I said first look for init param,
if that's not present check context.getAttribute(..).

This is the first time we're trying to have a "private" contract. Earlier, we had a called "jsp.class.path" which was being used. For the classloader we
either used Tomcat's classloader using some private API. If that wasn't there we used

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

Yep, yep. There are "reasonable" fallbacks. We can add more like
System.getProperty("jsp.class.path") :-)

Peace, Anil +<:-)

View raw message