You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Christopher K.St.John" <ck...@distributopia.com> on 2002/02/25 23:35:16 UTC

[PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670

 I posted to the dev list earlier about needing a small,
relatively lightweight version of Catalina to embed into
another program. I spent the weekend putting together
something that more of less fits my needs. (My needs 
include a relatively small jar, plus no use of the local
file system) I ended up with a 260k jarfile of the catalina
classes, plus another 75k or so of new Container classes.
I suspect there's at least another 100k that can be
trimmed.

 I ran into a troubling amount of coupling between the
various bits of Catalina. The o.a.catalina.* classes were
fairly clean, but the implementation classes tended to know
a lot about each other. That made reuse difficult, since
inheriting from one of the core classes ended up bringing
in pretty much every class (and external dependency) in
Catalina.

 The implementation classes obviously need to know
something about each other, but there are an awful lot of
hardcoded assumptions. The large number of casts makes
it very hard to figure out what depends on what.

 Instead of trying to make the core classes more generic,
I ended up writing a new set of Containers and support
classes. Using the existing Catalina code made that fairly
easy, but much of the code re-use was necessarily of the
cut-and-paste variety.

 There were a couple of especially inconvenient couplings
that are probably worth fixing, one trivial and one a little
more serious. I've submitted both of these as bugs.

 First, there's an uneeded import of org.xml.sax.AttributeList
in o.a.c.realm.RealmBase. That one's not such a big deal
since it doesn't matter at run time. The first of the
attached patches removes it.

 Second, there's a cast to StandardContext in AuthenticatorBase.
The cast is needed because AuthenticatorBase wants to use
the same debug level as its associated Context, but Container
doesn't expose the any set/getDebug methods. It would be good
to get rid of the cast because it's the only place that
BasicAuthenticator makes assumptions about the exact type of
its Context. The second patch just gets rid of the StandardContext
import and cast. A better solution might be to move set/getDebug
up into Container. Adding a Debug interface would work too, but
that seems like overkill. 

The MinimalTomcat code is definitely alpha quality, and it's
only meant to support the particular subset of Catalina that I
happen to need right at the moment. It is not, and is not
intended to be, a complete reimplementation of the Catalina
core classes. On the other hand, it's substantially smaller
and less complicated, while retaining the same basic architecture.
If anyone's interested, feel free to email me at the address
below, or respond on the list.



-- 
Christopher St. John cks@distributopia.com
DistribuTopia http://www.distributopia.com

Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670

Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Monday, February 25, 2002 5:29 PM
Subject: Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670


> > I posted to the dev list earlier about needing a small,
> > relatively lightweight version of Catalina to embed into
> > another program. I spent the weekend putting together
> > something that more of less fits my needs. (My needs
> > include a relatively small jar, plus no use of the local
> > file system) I ended up with a 260k jarfile of the catalina
> > classes, plus another 75k or so of new Container classes.
> > I suspect there's at least another 100k that can be
> > trimmed.
>
> > The MinimalTomcat code is definitely alpha quality, and it's
> > only meant to support the particular subset of Catalina that I
> > happen to need right at the moment. It is not, and is not
> > intended to be, a complete reimplementation of the Catalina
> > core classes. On the other hand, it's substantially smaller
> > and less complicated, while retaining the same basic architecture.
> > If anyone's interested, feel free to email me at the address
> > below, or respond on the list.
>
> Well, it's not that I want to advocate the "competition", but it seems to
me
> that Tomcat 3 is more useful for a "MiniTomcat", mainly because it
requires
> only JDK 1.1 (smaller JDK; J2ME is based on JDK 1.1, so maybe it could end
> up being a "target"; that was one of Costin's pet projects, actually).
>
The main problem that I would see is that you'd have to tweak some classes
to get TC 3.3 to run disk-less.  Otherwise, yes, Costin has done a lot of
work towards letting you run TomKitten 3.3 on your toaster.
> Remy
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670

Posted by Remy Maucherat <re...@apache.org>.
> I posted to the dev list earlier about needing a small,
> relatively lightweight version of Catalina to embed into
> another program. I spent the weekend putting together
> something that more of less fits my needs. (My needs
> include a relatively small jar, plus no use of the local
> file system) I ended up with a 260k jarfile of the catalina
> classes, plus another 75k or so of new Container classes.
> I suspect there's at least another 100k that can be
> trimmed.

> The MinimalTomcat code is definitely alpha quality, and it's
> only meant to support the particular subset of Catalina that I
> happen to need right at the moment. It is not, and is not
> intended to be, a complete reimplementation of the Catalina
> core classes. On the other hand, it's substantially smaller
> and less complicated, while retaining the same basic architecture.
> If anyone's interested, feel free to email me at the address
> below, or respond on the list.

Well, it's not that I want to advocate the "competition", but it seems to me
that Tomcat 3 is more useful for a "MiniTomcat", mainly because it requires
only JDK 1.1 (smaller JDK; J2ME is based on JDK 1.1, so maybe it could end
up being a "target"; that was one of Costin's pet projects, actually).

Remy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>