Re: preferred web environment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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


-- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list

[Index of Archives]     [CentOS]     [Kernel Development]     [PAM]     [Fedora Users]     [Red Hat Development]     [Big List of Linux Books]     [Linux Admin]     [Gimp]     [Asterisk PBX]     [Yosemite News]     [Red Hat Crash Utility]


  Powered by Linux