preferred web environment

[Bob Smith]

>There are good reasons to stick with apache 1.3.x. Some modules have/had
>problems with apache 2.0. I had a big problem getting getRemoteUser(),
>mod_jk or mod_jk2 and apache 2.0 to work properly. I've only recently
>found a work around (see tomcat bug 28516) but it's still an open issue
>as far as I'm concerned. Tomcat 5 is not that old either and I don't
>think Tomcat 4 is considered EOL. Heck, tomcat 3.3 is still in use.
>  
>
As you say later, it depends on your usage.  I just put together a 
project using Apache 2.0 and Tomcat 5, and as you point out, it took a 
little bit of effort to make the components work together.  However, it 
has been up and stable since early in the year.  Most software 
developers are going to go for the latest, and since Apache 2.0 is the 
current direction from Apache, it's not a bad idea to start your work 
with the latest.  Provided, as you point out, that you don't need to 
worry about backwards compatability with other applications. 

>Since Tomcat has it's own HTTP connector, there is an interesting debate
>on whether you need apache at all. My opinion:
>* if you need an apache module that Tomcat doesn't support, you probably
>need apache
>* if you do lots of static web pages, you might want apache (I've heard
>Tomcat's speed at serving static content is close enough to apache
>though).
>  
>
>I use apache because I do a lot with SSL certificates and doing it with
>apache is easier for me than with java and I imagine (but have
>absolutely no proof) that mod_ssl is faster than java ssl
>implementation. Also, I don't like Security Realms in Tomcat and prefer
>to do my own security using the user authentication info from apache.
>This is just me though, your requirements are probably different...
>  
>
Apache doesn't recommend using Tomcat to serve content only pages, 
although you can do it.  Apache is noticably faster than Tomcat at 
serving content, especially on high traffic servers.  There are also 
some memory management and threads issues with some of the Java 
implementations that can cause Tomcat to be flaky at times.  It is 
generally better to focus Apache on content and Tomcat on applications, 
just for performance reasons.  SSL is easier to handle in Apache, and 
the Tomcat docs recommend processing secure requests to Tomcat through 
the front end webserver, even though you can make Tomcat a secure 
server.  And, although Java based webservers are functional, in high 
volume systems you're better off going with something written in a lower 
level language. 

I agree with your point on JBoss.  Just to reaffirm, if you do need to 
support J2EE and EJBs fully, then JBoss is the way to go, since Tomcat 
does not support EJBs.  Having said that, in many instances, you really 
do not need to have an EJB implementation, as the EJB process overhead 
costs alot in the performance area, even more than a standalone Java 
based webserver.  If you have well written code, you can do the same 
things that an EJB implementation can do, but with better performance.  
Unless, of course, you need a resume rounder... :-)

That's my $0.02 worth!  :-)

-Bob