Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <C26EEF8D62108C4F86C695323A563F2F01B184F6@nyc0601.realpulse.com>
From: Aaron Smuts <ASmuts@therealm.com>
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
Subject: RE: [PATCH] MinimalTomcat, Coupling, Bugs 6669, 6670
Date: Mon, 25 Feb 2002 17:58:27 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1BE4F.EF6B1230"

------_=_NextPart_001_01C1BE4F.EF6B1230
Content-Type: text/plain;
	charset="iso-8859-1"

I'm very interested.  We should call it HouseCat.  I'd like to find a home
for it if it doesn't fit into tomcat.  


> -----Original Message-----
> From: Christopher K.St.John [mailto:cks@distributopia.com]
> Sent: Monday, February 25, 2002 5:35 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: [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

------_=_NextPart_001_01C1BE4F.EF6B1230--