Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Replacing StandardContext with a parallel implementation
Date: Fri, 18 Feb 2005 12:04:06 -0000
Message-ID: <DDBBD1E00935D144AB9563D57EF98D6221CA77@raccoon.melandra.net>
Thread-Topic: Replacing StandardContext with a parallel implementation
Thread-Index: AcUVsfHev47+OH3XRn2xdTYM6pMSGQ==
From: "Peter Crowther" <Peter.Crowther@melandra.com>
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>

I'm trying to produce my own Context implementation in Tomcat 5.0.28,
while otherwise keeping as many of the standard classes as possible.
It's not much fun; a couple of classes in catalina.core have package
visibility, and several others refer to StandardContext explicitly.
However, quite reasonably, StandardContext is not designed for
subclassing - many/most of its variables are private, and some crucial
decision points are buried deep within private methods that do many
other things.

None of this is a surprise, as Tomcat is intended to be a reference
implementation of the specs, and what I'm doing isn't a part of that.
All fair enough!  It does make things very difficult when you want
something that is like StandardContext but with a couple of differences,
as *either* you have to copy most of catalina (with appropriate
maintenance headaches) *or*:

- You have to copy the entire implementation of StandardContext, as it
is not designed for subclassing;

- You have to put your copied class in the catalina.core package, so
that it has access to the classes with package visibility;

- You *still* have to make your copied class be a subclass of
StandardContext, as otherwise the explicit references to StandardContext
elsewhere in Catalina cause errors.

- You are then trying to deal with StandardContext's calls to super() in
methods that you have to keep in your subclass (they refer to your local
variables), where your subclass and StandardContext both try to do the
same thing.

Is there a case for making it easier to create non-standard Contexts in
Tomcat?  Possibilities might include:

1. Construct an interface for the internal contract of a Context, and
make StandardContext implement that interface.  This breaks the
dependency on implementation inheritance.  This, to me, is the key one,
as it means that a copy of StandardContext can work.  Arguably, it's
also good design practice.

2. Possibly relax the visibility on the package-specific classes.  Less
useful - they've got package visibility for good reason, and it's
possible to get round this issue in other ways.

3. Possibly refactor StandardContext in a couple of places to bring key
decision points into their own methods that can be overridden by
subclasses.  Least useful, I think.

I've seen plenty of comments from the Tomcat maintainers that mods to
Tomcat that don't help it to achieve its goal of being a reference
implementation won't be considered.  I suspect that all of these mods
fall outside Tomcat's goal, but I want to run the first one - the
interface separation - past them, simply to confirm or deny that.  I'd
be happy to contribute the interface and mods for 5.0 and/or 5.5, but
want to check first whether it's worth doing, or whether the maintainers
will simply vote it out of the codebase.

Comments welcome.

		- Peter

--
Peter Crowther, Director, Melandra Limited
John Dalton House, 121 Deansgate, Manchester M3 2AB
t: +44 (0)161 828 8736  f: +44 (0)161 832 5683

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org