>> "Mangi" == Mangi, Rick <[EMAIL PROTECTED]> writes:
Mangi> Like any well planned out software project the ideal
Mangi> solution is derived
>> from the requirements. There are very few broad statements such as "Maybe
Mangi> for large volume servers, but for smaller servers (<10
Mangi> requests per second) it is NOT WORTHWHILE to do something
Mangi> else than Tomcat standalone" that hold true over the course
Mangi> of time.
Mangi> Is the only requirement for a web project the # of users
Mangi> and traffic? I have yet to come across such a project, and
Mangi> I've been at this for quite a long time. What are the
Mangi> security requirements? Do you have any legacy cgi code that
Mangi> tomcat can't handle well? Will you need to add any? Are you
Mangi> sure?
I didn't say there is not any situation thinkable where you might need
Apache for some other purposes (such as running CGI, filesystem
permissions etc), but even in that case one might consider running
Apache and Tomcat-standalone in parallel (on different IP addresses or
on different ports of course).
I truely think that almost all uses of the connector can be avoided,
and that servlet/JSP performance benefits from it.
Mangi> I'm not sure why people are so afraid to configure up
Mangi> apache. If you can get tomcat configured you most certainly
I am not afraid :). I did run Apache+JRUN and later Apache+Tomcat with
connectors for 2 years. But have come to the conclusion that in my
situation, and in many others, it is better and simpler to cut out
Apache.
For 100% servlet/JSP projects, you don't need Apache since the servlet
API can provide all authentification stuff that you need.
Mangi> Doesn't that transfer to server software as well? Tomcat is
Mangi> a servlet engine. Apache is a webserver. Sure tomcat can
Mangi> serve .gifs, and I could write a novel in Outlook, but I'd
A basic webserver is a very simple process that just reads a file and
sends it into a socket. Some complexity comes from multi-threading and
handling multiple connections, but that applies to handling servlets
too so is already included in any servlet engine.
As for performance, a modern JVM/JIT should have no problem in
reading/caching files and sending them to clients at maximum
(filesystem/network bandwidth) speeds. It is a trivial task that is
included in most/all servlet engines.
It doesn't add much bloat, specialization is no issue here.
Mangi> rather use a word processor. If we push the tomcat engine
Mangi> towards being a fully featured webserver isn't it
Mangi> eventually going to bloat? Won't the task we asked it to do
Mangi> (handle servlet/jsp requests) wind up suffering?
The 'bloat' in fully featured webservers doesn't come from being a
webserver itself (which is trivial); rather it comes from all kinds of
authentification schemes (which in a normal Servlet implementation
you'd solve in Java anyways, the JDBC realm being an example, or the
JNS (java naming service) features in tomcat. Or it comes from having
modules for all kinds of scripting languages (php, cgi, etc etc) that
are irrelevant in a non-legacy servlet environment.
--
Peter Mutsaers | Dübendorf | UNIX - Live free or die
[EMAIL PROTECTED] | Switzerland | Sent via FreeBSD 4.3-stable
