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 Tue, 16 Oct 2001 16:29:39 GMT


On Mon, 15 Oct 2001 cmanolache@yahoo.com wrote:

> Date: Mon, 15 Oct 2001 21:03:48 -0700 (PDT)
> From: cmanolache@yahoo.com
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Catalina on Avalon
>
> On Mon, 15 Oct 2001, Craig R. McClanahan wrote:
>
> > > I guess the two questions now are:
> > >
> > >  - *should* catalina packages be sealed? If so, why? If not, why not?
> > >  - what other advantages does Paul Hammat see in repackaging?
> > >
> >
> > Sealing can help in an environment where you cannot control what other
> > code gets loaded by the same class loader.  In this particular case (using
> > the standard Tomcat distribution hierarchy), the system administrator of a
> > Tomcat 4 installation is totally in control of what code goes here, by
> > virtue of their control over the /server/{classes,lib} and
> > /common/{classes,lib} directories.  It may or may not be different when
> > you package Tomcat under (or over -- can never get the directions right
> > :-) something like Avalon.
>
> That's true - the classes in org.apache... are protected by the class
> loader, so it is probably not needed.
>
>
> > In addition, my understanding of sealing says that we could seal
> > "org.apache.catalina" by creating a JAR file that contains only those 39
> > classes and interfaces (and sealing it), without messing with any of the
> > remainder of the implementation classes -- and without changing the
> > package hierarchy at all.  (I tend to get pretty focused on backwards
> > compatibility, having been bitten a few times.)
>
> Or at least make sure the 39 classes do not depend on the remaining
> classes, which is the case today.
>

Those dependencies fall into these categories:

* "org.apache.catalina.Cluster" depends on three classes from
  package "org.apadhe.catalina.cluster".  Because this is new
  and experimental code, I don't see as big a problem refactoring
  here.  Suggestions?

* "org.apache.catalina.Connector" depends on class
  "org.apache.catalina.net.ServerSocketFactory", which could be
  moved into the "org.apache.catalina" package fairly easily.

* "org.apache.catalina.{Context,Engine,Host}" depend on deployment
  configuration classes in package "org.apache.catalina.deploy".
  If the "org.apache.catalina" class were to be copied into a
  separate JAR, this package should be placed there as well.
  Otherwise, it would be confusing to combine them.  (None of
  these classes import anything else except RequestUtil, which
  could be examined for factoring/copying whatever the "o.a.c.deploy"
  package needs.

* "org.apache.catalina.{Engine,Host}" depend on class
  "org.apache.catalina.core.DefaultContext" which should have been
  created as an interface in the top-level package, with a corresponding
  implementation in "o.a.c.core".  This can be refactored pretty easily.

I'd still prefer to do things like this on the HEAD branch only.

>
> Costin
>
>

Craig




Mime
View raw message