tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core
Date Fri, 15 Oct 1999 02:17:00 GMT
Hans Bergsten wrote:

> "Craig R. McClanahan" wrote:
> >
> > "Anil K. Vijendran" wrote:
> >
> > > Ok. Let me understand this better. We're trying to
> > >
> > >   1. change the name from servlet.classpath to org.apache.jasper.classpath,
> > >   2. it would show in getAttributeNames()
> > >   3. it wouldn't be modified in setAttribute() -- what is the right thing to
> > >      do throw an exception? i don't like it. ignore it silently?
> > >
> >
> > I would like to suggest an alternative approach to this (and other analogous
> > situations that come up in the future).  It's based on a design philosophy I
> > feel pretty strongly about:  if you are going to pass around private
> > implementation details, do not use public interface mechanisms.
> >
> > 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 to
> > worry about, so there is no reason to hard code mangling into getAttribute()
> > and getAttributeNames(), and the intent is perfectly clear.
> 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.

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.

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.

> Hans


View raw message