Tomcat, Apache and the Jk Connector


Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Login/Register
By Davide Bianchi Tomcat seems to be the most used Application Server to serve JSP/Servlets, Apache is the most used Web Server, and the Jk is supposed to tie them togheter.

TomCat meet Apache

Apache is the most used Web Server, is free, fast and sleek, and that's good if you want to serve static html pages or you use a lot of CGIs (like this site).

But if you want to do something with JSP/Servlets you need an Application Server that knows something about Java. Tomcat seems the most used for this, even if in the last years he had some competition by other products (Bea WebLogic, IBM WebSphere, Macromedia JRun et similia). The big disadvantages of those, is that they are not free.

Tomcat 5 is fast enough to be used to serve static html without big troubles, so you could get away by using Tomcat alone both for static and dynamic html. But sometimes you want to do something more, like performing sophisticated url rewriting, load or bandwidth control and the like. So, having a fully-fledged web-server in front of Tomcat is a good idea.

The solution is to 'connect' TomCat with Apache, somehow.

To do so, you use a "connector", that is nothing more than a piece of software that is installed in Apache (static compile or loaded at runtime) and knows how to call TomCat when necessary passing the whole request for processing and passing back the results.

This, veeeeeeery shortly, is the whole concept behind the 'connector'.

Warning: this document is based on Apache 1.3.x and Jk 1.2.x on Linux, the same instructions apply to Apache 2.x, further revisions could add (maybe) different versions of the Connector, but don't hold your breath.

But I'm using Windows... Stop reading right here! I know nothing about Windows, never used Apache on Windows and, frankly, don't give a damn about it. If you're using TomCat to develop and test Servlets or JSP you don't need a connector, no reason to mess around with Apache, if you want to run Apache on Windows on a production server don't ask me how. Don't send me mail to ask for documentation or pointers: I don't know.

Jk1 or Jk2

The first "connector" was called "Coyote", why? I guess they liked the name. Then he becomes simply the "Jk".

When the Apache group started rewriting the whole Apache and built Apache 2, even the connector was rewrote and it came out as Jk2. The main difference between Jk1 and Jk2 was that the latter had the whole configuration file rewritten.

I never really liked the new "improved" configuration, too cumbersone and complicated. And, apparently, I wasn't the only one to not like it. After a while the (merry) news that Jk2 was dead and the work would have transferred on Jk1 spread around. So unless you have specific reasons to use Jk2, I suggest you get Jk1.

GearUp

What you need to use TomCat/Apache/Jk? Well, you need Apache. Installed and working. With "working" I mean that opening a browser and pointing it to http://ip.of.the.server/ should show a cheerful page with "if you can read this it means your server is working".

If it doesn't, then is time to read the Apache documentation and fix it before continuing.

Warning!!! Before you begin whine and send me mail about the fact that it doesn't work remember that: 1) the default configuration of Apache does work. So save the default config file before screwing it completely. 2) If Apache doesn't work there is no sense in going forward with more screw up. One damn thing at a time.

Then you need TomCat. Installed and working too. TomCat works by default on port 8080, so if you open another browser on http://ip.of.the.server:8080 you should see another merry page with "Tomcat" written all over the place.

Again, if it doesn't work, read the documentation. No sense in going on until both Apache and Tomcat don't work on their own. And again, the default configuration of Tomcat does work.

The Jk. Yeah, sure, you need it. On Apache web site you can find a pre-compiled binary or the source of the entire thing. Now, I've never had any luck with the pre-compiled, for some reasons they've never worked with me. So I always compile my own Jk.

To compile the Jk you need a C compiler and the whole lot of tools (automake, autoconf, make, linker...). If you don't have this stuff or you don't have the possibility to install them, then maybe you can try with the pre-compiled version. Otherwise you can see if your distribution does have a pre-compiled somewhere.

Let's suppose you have all the tools and you want to compile the code. Good: download the sources and unpack them somewhere, a ton of junk came out from the package, but the only thing you need is in the jk/native subdir.

Read the README and BUILDING file in there isn't a bad idea. In short: ./configure and then make. After that, you have in apache- the mod_jk.so. Just copy this where the other Apache modules are and you should be ready.

NOTE: if you don't want to use a dynamic module but you want to have it statically compiled in Apache, follow the instructions on Apache's web site.

Configuration

Configuring the connector is a matter of editing two files: workers.properties (the name is not mandatory, this is just the default) and the standard httpd.conf for Apache (again: this is just the default).

httpd.conf
In httpd.conf you have to add:

LoadModule jk_module /where/is/mod_jk.so

JkWorkersFile   /where/is/workers.properties
JkLogFile       /where/you/want/jk_log        
JkLogLevel      debug
JkMount         /servlets-examples/*    ajp13
If Apache's modules are not immediately found (meaning: other LoadModule directives have some path) then you have to specify the same path. In my installation modules are in libexec/apache/ so my httpd.conf reports libexec/apache/mod_jk.so.

The same way you have to specify the path of the workers.properties file and where you want the log file.

workers.properties
This file contains the configuration for the various processes that communicate with TomCat. Minimum you need one "worker", nothing stops you to have multiple workers with different configuration. See the documentation for more info on this.

A minimal configuration is the following:

# workers.properties -
workers.tomcat_home=/usr/local/tomcat
workers.java_home=/usr/lib/java
ps=/

worker.list=ajp13
worker.ajp13.port=8009
worker.ajp13.host=localhost
worker.ajp13.type=ajp13
Of course, "tomcat_home" must point where TomCat is installed on your machine, and "java_home" the place where Java is.

The "port" and "host" entry refers to where Tomcat is listening, the default configuration is on port 8009. Attention: for 'listening' I mean where tomcat is listening for connection throught the connector, not using http. They are different.

Attention: The type of worker is ajp13 for Tomcat 5 and ajp12 for Tomcat 4. Don't mix them up.

When this is done, you should be able to issue an httpd -t or apachectl configtest and ess an "Ok", meaning: the configuration file is ok and the module can be loaded fine.

Test the connector

If you've done the basic configuration and TomCat is working, you should be able to restart (or start) Apache and connect to http://ip.of.the.server/servlets-examples/ and see TomCat's example page in his full glory. Everything should work just like typing the :8080 part but without doing it.

This means that the connector is working and TomCat is called into action when it has to.

But when ti has to? This is the pourpose of the JkMount directive that is in the httpd.conf.

In short, every 'directory' defined in JkMount is 'passed' to TomCat trought the defined worker.

JkMount	/servlets-examples/*	ajp13
This means: whenever an URL starts with /servlets-examples/ call the workers defined ajp13.

We can add other JkMount directives and call TomCat for other applications. For example, adding

JkMount	/manager/*	ajp13
And restarting Apache, we should be able to call the Manager application trought apache. Note: the default configuration of TomCat doesn't allow any login in the Manager Application, you need to define at least one user with "role" manager in tomcat-users.xml.

And if I don't want the connector?

The connector sucks! I don't want it!

Suit yourself! The alternative is to use mod_proxy to call TomCat when necessary, like:

ProxyVia Off
ProxyPass	/application/	http://ip.of.server.here:8080/application/
ProxyPassReverse  /application/	http://ip.of.server.here:8080/application/

This basically does the same but is more brutal and the connector has more configuration options. See the documentation of the connector himself.

Nothing works here!

If you added an application on TomCat and can't get to it trought the connector, you can follow some steps to debug it.

  1. Be sure that TomCat knows about the new application

    Meaning: open your browser on http://...:8080/yourappshere/ and be sure that you get your application. Be sure that everything in your application works when called directly. If it doesn't work like this, there is no sense in expecting that it works from Apache.

  2. Check if JkMount works

    If you added a JkMount directive and then type the URL you get an error from Aapche, it means that Apache doesn't see the JkMount directives. Remember that Apache's error have "Apache...something" written as last line, while TomCat contains "Apache Tomcat/something". Be sure you clean the cache of your browser before trying again.

  3. Check if JkMount refer to the application

    If your application is Application1 and you have "mounted" it as Application2 probably it won't work.


Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.

10 messages this document does not accept new posts
barlemiUna sciocca domanda By barlemi - posted 01/04/2010 15:30
Salve, volevo capire una cosa che non mi è chiara ma se apache e tomcat risiedono su due server diversi come vanno configurati i file? e in che modo apache e tomcat comunicano tra loro?

--
barlemi


Davide Bianchi@ barlemi By Davide Bianchi - posted 01/04/2010 16:50

> Salve, volevo capire una cosa che non mi è chiara ma se apache e tomcat risiedono su due server diversi come vanno configurati i file?

Invece di indicare 'localhost' nel workers.properties ci si mettera' l'indirizzo IP del server TomCat.

> e in che modo apache e tomcat comunicano tra loro?

Usando il protocollo AJP che e' descritto sul sito di Apache (per i curiosi)

--
Davide Bianchi


MassimilianoSciocca Domanda 2 By Massimiliano - posted 23/04/2010 21:17

Fa sempre piacere trovare le cose che cerchi nel sito che preferisci. Ad ogni modo ho una, anzi due domande da farti:
a) Sto cercando duramente di configurare lo stesso ambaradan, seguendo tipo 4500 guide, ognuna che riporta qualcosa di diverso. La tua coincide con un'altra per cui mi fa ben sperare che sono sulla buona strada. La domanda e': pensi che l'avere il S.O. con architettura a 64 bit, apache a 32 (non si trova a 64...) e tomcat a 64, possa creare qualche problema?
b) L'altra guida che ho trovato segnalava la necessità di modificare il file server.xml. E' un file che fa parte del marasma di file xml che hai citato nell'articolo oppure e' un qualcosa che non serve modificare?
Grazie. Bye.

--
Massimiliano


Davide Bianchi@ Massimiliano By Davide Bianchi - posted 24/04/2010 12:12

> pensi che l'avere il S.O. con architettura a 64 bit, apache a 32 (non si trova a 64...) e tomcat a 64, possa creare qualche problema?

Dato che i due comunicano tramite un socket non dovrebbe comportare alcun problema. Aspetto di essere smentito dalla pratica.

> b) L'altra guida che ho trovato segnalava la necessità di modificare il file server.xml.

Il server.xml e' di TomCat e ti serve modificarlo se vuoi cambiare le porte su cui TomCat ascolta e robe cosi'. Vedi l'altro articolo sui VHosts in TomCat per qualche esempio.

--
Davide Bianchi


Massimiliano@ Davide Bianchi By Massimiliano - posted 24/04/2010 18:46

> > pensi che l'avere il S.O. con architettura a 64 bit, apache a 32 (non si trova a 64...) e tomcat a 64, possa creare qualche problema?
>
> Dato che i due comunicano tramite un socket non dovrebbe comportare alcun problema. Aspetto di essere smentito dalla pratica.
>
> > b) L'altra guida che ho trovato segnalava la necessità di modificare il file server.xml.
>
> Il server.xml e' di TomCat e ti serve modificarlo se vuoi cambiare le porte su cui TomCat ascolta e robe cosi'. Vedi l'altro articolo sui VHosts in TomCat per qualche esempio.
>

Dopo un numero non meglio precisato di peccati sono riuscito nel mio intento, anche se ho utilizzato appianato tutta la faccenda usando solo applicativi a 32 bit. Debbo dire che per riuscire nell'impresa ho fatto un merge di informazioni di due guide e una ventina di forum.
A titolo informativo, per coloro i quali fossero incappati anche nella guida che parlava di modificare il file server.xml: non serve farlo.
Ciao BigD.

--
Massimiliano


Anonymous rabbit.. con i virtualhost By Anonymous rabbit - posted 04/08/2010 15:01

Bisogna mettere
JkMountCopy On
dentro il virtualhost altrimenti non funge.

apache 2.2 + tomcat 6

--
Anonymous rabbit


Daniele By Daniele - posted 22/04/2011 09:48

Se io volessi che la mia applicazione Tomcat, che attualmente si trova su http://server:8080/nome-applicazione-troppo-lungo, venisse servita da Apache all'indirizzo http://server/applicazione, come devo fare?

C'è qualche direttiva specifica da aggiungere ai file di configurazione?

Oppure l'unica alternativa è quella di rinominare opportunamente la directory di Tomcat in cui risiede l'applicazione?

--
Daniele


Davide Bianchi@ Daniele By Davide Bianchi - posted 24/04/2011 07:06

Se io volessi che la mia applicazione Tomcat, che attualmente si trova su http://server:8080/nome-applicazione-troppo-lungo, venisse servita da Apache all'indirizzo http://server/applicazione, come devo fare?



L'applicazione viene 'servita' da TomCat a seconda del 'context' specificato nel file di configurazione dell'intero tomcat (server.xml) o della specifica applicazione (web.xml), si puo' intervenire in quei due e risolvere il problema dal lato di tomcat, oppure usare un diverso ProxyPass:




ProxyPass /applicazione http://localhost:8080/nome-applicazione-troppo-lungo
ProxyPassReverse /applicazione http://localhost:8080/nome-applicazione-troppo-lungo


--
Davide Bianchi


Daniele By Daniele - posted 23/04/2011 08:17

Altra domanda...

Io ho due applicazioni Tomcat, e vorrei che ognuna venisse pubblicata su un Virtual Host diverso, del tipo: http://vhost1/applicazione1 e http://vhost2/applicazione2.

Ovviamente vorrei anche che http://vhost1/applicazione2 e http://vhost2/applicazione1 non funzionassero, magari segnalando errore, oppure pagina non trovata, o qualsiasi altra cosa: l'importante è che l'applicazione 1 sia SOLO sul Virtual Host 1 e non sul 2 (e viceversa).

Si può fare? E se sì, come?

--
Daniele


Davide Bianchi@ Daniele By Davide Bianchi - posted 24/04/2011 07:10

ho due applicazioni Tomcat, e vorrei che ognuna venisse pubblicata su un Virtual Host diverso, del tipo



Io userei una rewrite di apache per redirigere tutto cio' che non e' "/applicazione1" di vhost 1 verso /applicazione1 ed idem per vhost 2 ed applicazione 2, ma questo non ha niente a che vedere con TomCat in effetti, vedi la documentazione di Rewrite sul sito di Apache.


--
Davide Bianchi


10 messages this document does not accept new posts

Previous


Davide Bianchi, works as Unix/Linux administrator for an hosting provider in The Netherlands.


Do you want to contribute? read how.  
 


This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.


This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.

This site isn't optimized for vision with any specific browser, nor it requires special fonts or resolution.
You're free to see it as you wish.

Web Interoperability Pleadge Support This Project
Powered By Gojira