tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Catalina on Avalon
Date Sun, 14 Oct 2001 00:24:21 GMT


On Sat, 13 Oct 2001, Paul Hammant wrote:

> Date: Sat, 13 Oct 2001 16:40:44 +0100
> From: Paul Hammant <Paul_Hammant@yahoo.com>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> Subject: Catalina on Avalon
>
> Hi folks,
>
> As mentioned some weeks ago, I have Catalina more or less working inside
> Avalon.  In short this means it can run inside the same virtual machine
> as JAMES (mail server) FtpServer (another Avalon app) and other servers.
>  See picture at this link :  http://jakarta.apache.org/avalon/phoenix/
>
> Request :
>
>     Summary : Seperation of  interfaces and implementation.  Different
> jars in same ditribution.
>
>     Detail : There are 39 interfaces & support classes in
> org.apache.catalina.  Sub packages of that implement those abstractions.
>  It's a very neat design apart from one thing.  They are all in the same
> jar file and hence classloader.  In Avalon we mount classloaders one or
> two levels deeper than the primordial that would load the core of
> Catalina if launched from a shell.  We'd like to be able to mount the
> interfaces at top level for general visibility and sharing, and
> implementation, like other server applications in a branch/leaf class
> loader.   If those 39 interfaces and classes were moved to a different
> package (say org.apache.catalina.api), then a split into two jars would
> be possible and our dreams could come true.
>
> Have I convinced of need?
>

I can see why you might wish to have the "39 interfaces and support
classes" packaged in a separate JAR file.  I haven't yet been convinced
why they should be moved to a different package, which would break 100% of
the applications that rely on the current package names.

> Is 4.0.1 beta too touchy a distribution to instigate package migrations
> on (however trivial) ?
>

Definitely.  In fact, I would -1 a package name change on *any* release in
the 4.0.x family -- backwards-incompatible changes that are this
substantial are bad news.

> Regards,
>
> - Paul H
>
>

Crig



Mime
View raw message