Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Sender: "Craig McClanahan" <cmcclanahan@mytownnet.com>
Message-ID: <38068943.D0086B30@mytownnet.com>
Date: Thu, 14 Oct 1999 18:54:11 -0700
From: "Craig R. McClanahan" <cmcclanahan@mytownnet.com>
Organization: MyTown Network, Incorporated
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core
 Context.java
References: <19991014235741.9786.qmail@hyperreal.org>
 <380677D6.AF7A0163@eng.sun.com> <38067998.59499C7@eng.sun.com>
 <38067BBB.5ADA62E7@eng.sun.com> <38068009.D60E4428@eng.sun.com>
 <380681E4.A5F03E10@eng.sun.com> <3806860E.B0B0C904@eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

In Apache JServ, I codified this by taking a slightly different approach
(you'll hear more about this in the future):

* The analogue to Context is an interface not a class.
  It contains only those methods that I felt were important
  in any implementation of the servlet context concept.

* There is an additional interface InternalContext that
  extended Context, and defines the stuff specific to
  this implementation.

* StandardContext is the implementation class and implements
  InternalContext (and therefore Context).

* Other places that dealt with generic Context variables could
  use all the public methods at will.  If they needed to refer to
  implementation-specific stuff, they cast it to InternalContext.

Craig McClanahan