tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Can TomCat run WITHOUT Apache?
Date Sun, 25 Jan 2009 14:18:21 GMT
Ok, I'll bite, and improve a bit on Gregor's correct but rather terse 
response.

thoste wrote:
> Sorry for this newbie question:
> 
> Can TomCat run WITHOUT Apache?
Yes.

> 
> AFAIK "yes". Apache is only useful when performance for static HTML pages is
> needed.
The answer to that is more nuanced.
Tomcat can serve static content such as HTML pages, images, stylesheets 
etc.., maybe as fast as Apache does, once its machinery is up and 
running.  It is (for the moment) a bit less "sophisticated" than Apache 
httpd for that purpose, in the sense that it does not have, in the 
standard Tomcat distribution, as many "additional features" such as 
caching, proxying, URL rewriting, AAA variations, etc.., all things that 
would make more complex configurations possible "out of the box".
Under Tomcat, you would have to achieve such things using additional 
servlets and servlet filters, which might or might not be as readily 
available as the corresponding Apache "modules".
Another thing you don't have in Tomcat, but do have in Apache httpd, is 
the availability of some modules which optimise the running of external 
scripts or other "server-side active pages" such as PHP, Perl, Python, 
Ruby etc..

On the other hand, Apache httpd by itself cannot run Java servlets.

Another thing to point out is that, to serve purely static content, 
Tomcat will probably consume quite a bit more RAM than Apache would for 
the same thing (say a factor 10 at least).  But as soon as you have at 
least one Java servlet to run, serving static content also won't make a 
difference.

Now, if your purpose is mainly to run Java applications and accessorily 
some static content, then using Tomcat alone will probably be more 
efficient than configuring it with an Apache httpd front-end, which will 
only add some overhead to most requests.

On the other hand, if your server is not heavily loaded, and you want to 
preserve a lot of future flexibility in terms of all the "additional 
features" mentioned earlier, then using an Apache front-end will not 
kill your server, and doing this from the start will make your life a 
lot easier for the day when you need these features.

> 
> On the other side TomCat can run independently from Apache and can serve as
> a server 
> for the following techs:
> 
> Servlets, Java Server Faces, Java Server Pages, Hibernate, Ajax,
> Javascript+"normal" HTMP web pages
> 
> Is this statement correct?
Basically yes, except that Ajax and Javascript don't really have 
anything to do with Apache httpd or Tomcat per se.  They are client-side 
things.  Your httpd server (Apache httpd or Tomcat) processes HTTP 
requests, and does not really care if they come from a browser directly, 
or from some Javascript or Ajax function embedded in an HTML page.  That 
also extends to Java applets by the way.

Let's put it this way : Tomcat is a Java servlet engine, which means it 
is a program whose main purpose is to provide an environment for running 
Java servlets, as defined in the Java Servlet Specification.
In other words, Tomcat provides a "comfortable home" for a special kind 
of Java program known as a servlet; in this home, a servlet can expect a 
known environment, to be called in a certain way, and make itself use of 
a number of standard interfaces to process and manipulate web requests 
and responses.
JSP pages and all the rest you mention above are additional layers on 
top of that, in the sense that they are first pre-compiled into Java 
servlets, which are then run "inside" Tomcat.
And there exists a standard (or default) servlet embedded in Tomcat, 
whose function is to serve static content.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message