tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <>
Subject Re: Catalina 1.0 vs. Tomcat 4.0
Date Sat, 19 Aug 2000 14:34:03 GMT
> I don't want to open old wounds, but I thought I'd just explain my
> tardy -1 (or -0 if I'm the only one) on renaming Catalina to Tomcat
> 4.0.
> The mandate of the Jakarta Project is to produce a servlet container
> that implements version X of the servlet and JSP specs.  There's no
> mandate for this container to always be named Tomcat.


> Fact: Catalina is (as everyone knows) a 99% different code base (I
> think the connectors will be reused, and some of the utility classes).

Ok. Usually in open source, a major revision number change is more
significant than in commercial software. It also means that a good part of
the product, if not everything, has been rewritten, so I don't see any
problem here.

> Fact: Tomcat has a long history of being improved, bugs fixed,
> robustness tested on thousands of platforms, tweaks and custom
> features added; it will be a long time until Catalina has this level
> of maturity.

We have to decide when too mature is too much ;-)
To give an extreme exemple, the DOS code in Win ME is probably extremely
mature, yet I would have liked to see it go away a long time ago.

> Fact: Even once it does, there may be people who want to use custom
> patches/Interceptors/etc., and will require support for their existing
> Tomcat 3.x installs, and will most likely keep coming up with patches
> for Tomcat 3.x.

Our friends from Apache are doing just that with Apache 2.0. They're
rewritting everything from scratch : the webserver, the configuration files
format, the API.
BTW, at one point, there was an InterceptorValve which could be used to wrap
Tomcat interceptors. It seems it had been removed at some point, though
(Craig ?).

> Fact: many sites have customized the server.xml config file; as I
> understand it, there will not be backwards compatibility for all
> (any?) aspects of Tomcat's server.xml in Catalina (though I may be
> wrong here).

I don't think that's a big deal. They're quite similar ...

> Fact: Tomcat 3.x will soon support the new specs too, via Facades.


> Fact: Catalina has many advantages too, and I trust Craig et al.'s
> faith in the new design and code.

I trust him too ;-)

> Speculation: If Catalina is released as Tomcat 4.0, then we will end
> up with two separate products, with separate development efforts,
> separate code bases, and unfortunately and confusingly, the same name,
> leading to misunderstandings across the board.  E.g., if a security
> hole or performance problem is discovered in one, then the reputation
> of the other will suffer.

I don't see why the Tomcat 3.x code base would have to be maintained in
parallel for a very long amount of time.

> Proposal: that Catalina keep its name, and be designed for release as
> Catalina 1.0, and we make it as clear as we can, on the web site and
> in the docs and announcements, that Catalina is the recommended
> container, and is where most new development will occur.
> The only disadvantage I can see is that people will constantly ask,
> "Which one should I use, Catalina or Tomcat," but this FAQ can be
> answered clearly in big bold letters on both the Tomcat and Catalina
> home pages and anywhere else that's appropriate.
> I know that the change in name has already happened, and I apologize
> for being on holiday when this thread was launched, but I'd like at
> least a token attempt to convince me that these concerns have been
> considered and deemed moot.

Apache does it with Apache 1.3 and Apache 2.0. Jakarta should be able to do
the same too with Tomcat.

I don't know a lot about marketting, it's not my job, but the trend seems to
be towards releasing products with the same name, but with higher version
number. Since the two products perform similar functions, I think it would
be a mistake to have two different names.

> If there's an old thread where this was hashed out, please point me to
> it (perhaps by date, so I can narrow my search of the archives).


View raw message