tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "simon" <>
Subject Re: Ideas for future versions of Tomcat (a bit controversial maybe)?
Date Tue, 02 Oct 2001 00:32:04 GMT
So couldn't  we make it a configurable option?   Or, if it had a fundamental effect on the
design, couldn't we have  - yet another
:o) - major version of tomcat 3, 4, 5?

I definitely agree with Chris that the benefits would be too good to ignore.  It could also
make using Tomcat standalone viable,
which would get rid of this dependency on mod_jk and mod_webapp.  (I do appreciate the work
done on these but this list does get a
lot mail about configuring these modules).

----- Original Message -----
From: "Ralph Einfeldt" <>
To: <>
Sent: Monday, October 01, 2001 6:21 PM
Subject: AW: Ideas for future versions of Tomcat (a bit controversial maybe)?

Technically I like that idea.

BUT expierence shows that it is not a good option
to jump to early on new JDK for tools like tomcat.

>From listening to this list, I've got the feeling
that there are several people in the world that
don't have the will or the chance to upgrade to
the newest JDK. Some use operating systems that
are always a bit behind with the JDK (AIX, Mac OS,
...) some deploy to an ISP that won't upgrade that

> -----Urspr√ľngliche Nachricht-----
> Von: chris brown []
> Gesendet: Montag, 1. Oktober 2001 10:54
> An:
> Betreff: Ideas for future versions of Tomcat (a bit controversial
> maybe)?
> Hello,
> I've been trying out JDK 1.4 quite a lot, and like it a lot!  I was
> wondering, given that Tomcat is a "reference implementation" of the
> Servlet/JSP APIs, if it would be a good idea to become a very
> good example
> of certain new APIs as well.
> I've suggested a while back that the "New scalable I/O"
> channels could be
> used to boost performance.  Since then, I've seen other
> opportunities for
> increasing effeciency, simplifying code, etc.  For example, instead of
> maintaining and downloading APIs for logging, it might be
> better to depend
> upon the newer logging APIs.  The same thing could be said of certain
> example applications (such as making Struts use the
> java.util.regex package
> instead of an external regular expression package -- but
> then, that's going
> a bit OT as there's a list for Struts too...!).  Perhaps also the
> configuration could be stored using the preferences API, but
> I don't see so
> many benefits with a change of this type.
> Obviously, this would limit the accessibility of any such
> future version
> Tomcat to users of JDK 1.4, but I don't think that's a major
> problem in the
> majority of deployment situations (I'm guessing here, but I
> suspect it's
> quite likely to be true).  Nevertheless, I think it would be
> a good step
> forward.
> -Chris

View raw message