>> "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