Tomcat, Apache ed il Jk Connector

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

10 messaggi this document does not accept new posts

Una sciocca domanda Di barlemi postato il 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

@ barlemi Di Davide Bianchi postato il 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

Massimiliano

Sciocca Domanda 2 Di Massimiliano postato il 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

@ Massimiliano Di Davide Bianchi postato il 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 Di Massimiliano postato il 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 Di Anonymous rabbit postato il 04/08/2010 15:01

Bisogna mettere

JkMountCopy On

dentro il virtualhost altrimenti non funge.

apache 2.2 + tomcat 6 -- Anonymous rabbit

Daniele

Di Daniele postato il 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

@ Daniele Di Davide Bianchi postato il 24/04/2011 07:06

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

Di Daniele postato il 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

@ Daniele Di Davide Bianchi postato il 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 messaggi this document does not accept new posts

TomCat incontra Apache		Apache e' il piu' diffuso Web Server, e' gratuito, efficiente e veloce, il che va benissimo se volete distribuire pagine statiche o se vi dilettate nella progettazione e programmazione CGI (questo sito ne e' un esempio). Ma se volete fare qualche cosa con JSP/Servlets vi serve un'Application Server che capisca Java. E Tomcat sembra sia il piu' usato in assoluto. Benche' ultimamente abbia avuto una seria concorrenza da parte di altri prodotti (Bea WebLogic, IBM WebSphere, Macromedia JRun et similia). Solo che tutti questi sono a pagamento, mentre Tomcat rimane sempre gratuito. Tomcat 5 e' sufficientemente veloce da poter essere usato da solo come Application Server e come Web Server, sia per pagine 'dinamiche' che per pagine 'statiche' quindi, ma molti preferiscono avere qualche cosa 'di fronte' che consenta giochetti sofisticati come Url Rewriting, Load Balancing et similia. La soluzione semplice e' quella di 'collegare' insieme in qualche modo Apache e Tomcat. Per questo si usa un "connector" che altro non e' che un pezzo di software che si installa in Apache (compilandolo staticamente o caricandolo come modulo a runtime) e che 'chiama' Tomcat quando necessario passando la palla quando istruito. Questo, mooooolto in breve, e' il concetto dietro al "connector". ATTENZIONE: questo documento si basa su Apache 1.3.x e Jk 1.2.x su Linux. Le stesse istruzioni si applicano anche ad Apache 2.x. Ulteriori revisioni potranno (forse) riferirsi a diverse versioni del connector, ma non contateci troppo. Ma io uso Apache su Windows... Stop! Smettete di leggere adesso! Non so un fico secco di Windows, non ho mai usato Apache su Windows e non ci tengo molto a farlo adesso. Se state usando TomCat per sviluppare e testare Servlets e JSP non vi serve un connector, potete usare TomCat direttamente senza preoccuparvi di connectors, se pretendete di far funzionare Windows come server di produzione non domandate a me. Non mandatemi mail chiedendomi dove trovare documentazione o istruzioni: non lo so.
Jk1 o Jk2		Il primo "connector" per Apache venne chiamato "coyote". Perche' "coyote"? Probabilmente gli piaceva il nome. Poi divento' semplicemente JK. Quando il gruppo Apache inizio' a ri-scrivere da capo tutto e creo' Apache 2, decisero anche di riscrivere da capo il Jk e venne alla luce Jk 2. Jk2 aveva una particolarita': tutta la configurazione era fatta in XML. Ora, se voi adorate l'XML va tutto bene. Io lo trovo un'inutile complicazione, quindi ho sempre cercato di starne molto lontano. Apparentemente non ero l'unico a pensarla cosi', difatti dopo un po' si sparse la (lieta per me) novella che Jk2 era definitivamente morto ed il lavoro sarebbe proseguito solo su Jk1. Quindi, se non avete particolari motivi (avete sviluppato codice specifico per Jk2), usato il Jk1 e vivete felici.
GearUp		Cosa serve per far funzionare Tomcat/Apache/Jk? Be', prima di tutto vi serve Apache. Installato e (possibilmente) funzionante. Con questo intendo che, aprendo un browser e digitando "http://ip.del.server.qui/" dovrebbe saltarvi fuori una paginetta con su' scritto qualche cosa del tipo "Congratulazioni, se vedete questo significa che il vostro Apache Web Server funziona". Se non funziona... cominciate a leggervi la documentazione di Apache. ATTENZIONE!! Prima di cominciare a piagnucolare e mandarmi mail relative al fatto che non funziona niente ricordatevi che: 1) la configurazione di default di Apache FUNZIONA, quindi salvatevi i files di configurazione di default prima di masturbarli oltre ogni possibilita' di salvezza. 2) Se fin dall'inizio Apache non funziona non c'e' senso ad andare avanti con ulteriori masturbazioni, una dannata cosa alla volta. Poi vi serve Tomcat, anch'esso installato e funzionante. Tomcat funziona di default sulla porta 8080, quindi se aprite un'altro browser e digitate "http://ip.del.server.qui:8080/" dovreste vedere un'altra bella paginetta che dice "Congratulazioni, il vostro Tomcat funziona". Anche qui, se non funziona leggetevi la documentazione di Tomcat, non c'e' senso nel continuare se non avete i due pezzi (Apache e Tomcat) funzionanti per conto loro prima di cercare di metterli insieme. Anche qui, la configurazione di default funziona, quindi salvatevi i files di configurazione prima di demolirli. Il JK. E gia', vi serve il Jk. Sul sito di Apache e' possibile scaricare un binario pre-compilato o i sorgenti dell'intero accrocchio. Io non ho mai avuto fortuna con i precompilati (per qualche motivo non mi hanno mai funzionato) e cosi' ho sempre compilato il mio Jk per conto mio. Per compilare il Jk vi serve un compilatore (DOH!) e tutto il necessario (automake, autoconf, make, librerie varie). Se non avete tutta sta' roba installata o non avete la possibilita' di installarla e' un'idea il tentare il precompilato o vedere se la vostra distribuzione fornisce il Jk pre- compilato da qualche parte, altrimenti la vedo dura. Supponiamo che voi abbiate il compilatore e tutto l'armamentario e vogliate compilarvi il vostro Jk. Bene: scaricatevi i sorgenti e scompattate il tutto da qualche parte. Salta fuori una marea di roba. Quello che interessa a voi e' solo in jk/native/. Leggersi il README ed il BUILDING non e' una brutta idea. In breve: ./configure, make. Dopo di che in apache- vi ritrovate mod_jk.so. Copiate questo file dove sono gli altri moduli di Apache e siete quasi a posto. Ora si tratta di configurare il tutto. NOTA: se non volete usare il modulo dinamico ma preferite compilare il modulo staticamente, seguite le istruzioni sul sito di Apache.
Configurare il tutto		La configurazione del connector si basa sulla modifica di due files: uno chiamato workers.properties (o come vi pare, questo e' solo il default) ed il normale httpd.conf (o come avete chiamato il vostro file di configurazione di apache). httpd.conf In httpd.conf e' necessario aggiungere: LoadModule jk_module /dove/sta/mod_jk.so JkWorkersFile /dove/sta/workers.properties JkLogFile /dove/volete/jk_log JkLogLevel debug JkMount /servlets-examples/* ajp13 Se i moduli di Apache non sono immediatamente trovabili (aka: nelle altre LoadModule e' specificato un path) dovrete specificare lo stesso path anche qui'. Nella mia installazione per esempio i moduli si trovano in libexec/apache/, quindi il mio httpd.conf contiente libexec/apache/mod_jk.so invece che semplicemente mod_jk.so. Allo stesso modo dovrete specificare la posizione del workers.properties (again: questo e' il default, non e' obbligatorio chiamarlo cosi') e di dove volete il file di log. workers.properties Il Workers e' il file che contiene la configurazione per i vari processi di comunicazione con tomcat. Come minimo vi serve 1 worker, ma niente vi impedisce di averne molteplici. Una configurazione minimale e' la seguente: # 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 Ovviamente 'tomcat_home' deve riportare dove e' installato tomcat sul vostro sistema, allo stesso modo java_home deve riportare dove e' installato java sul vostro sistema. Port ed Host devono riferirsi alla porta ed all'Host su cui e' in ascolto Tomcat. In questo esempio io assumo una configurazione di default, percui Tomcat e' in ascolto sulla porta 8009 sullo stesso server (localhost). Attenzione: per "in ascolto" intendo dove TomCat ascolta per il connector, non dove ascolta per http. Non confendete le due cose. Attenzione: Il tipo di worker e' ajp13 per default in tomcat 5 e ajp12 per tomcat 4. Quando avete fatto queste modifiche dovreste essere in grado di eseguire httpd -t o apachectl configtest ed avere come risposta un "Config ok", che significa che tutto pare a posto almeno da questa parte.
Provare il connector		Se avete fatto la configurazione di base ed avete Tomcat funzionante, avviate (o ri-avviate) Apache e provate a richiamare dal browser http://ip.del.server.qui/servlets-examples/. Se tutto e' OK dovreste vedere la pagina di esempio delle servlet di TomCat, e tutto dovrebbe funzionare come se aveste richiamato direttamente TomCat (con :8080 nell'URL insomma). Questo significa che il connector funziona e richiama TomCat quando deve. Ma quando deve? Questo e' lo scopo della direttiva JkMount che e' riportata in httpd.conf. Se guardate la configurazione proposta sopra, abbiamo aggiunto un JkMount /servlets-examples/* ajp13 Che significa in breve: tutto quello che comincia con /servlets-examples/ mandalo al connector ajp13. Il connector non fa' altro che 'girare' la richiesta a Tomcat. Se aggiungiamo altri 'JkMount' possiamo richiamare TomCat per altre applicazioni. Per esempio aggiungendo JkMount /manager/* ajp13 E ri-avviando Apache, dovreste essere in grado di richiamare l'application manager di TomCat direttamente. O almeno vedere la richiesta di login. Nota: la configurazione di default di TomCat non consente nessun login, dovrete modificare /dove/sta/tomcat/conf/tomcat-users.xml ed aggiungere almeno un'utente con "ruolo" admin e manager.
E se il connector non lo voglio?		Il connector e' una rottura di scatole! Non lo voglio! Fate come vi pare. L'alternativa e' usare mod_proxy e "proxare" le richieste verso un'applicazione verso Tomcat stesso usando: ProxyVia Off ProxyPass /application/ http://ip.del.server.qui:8080/application/ ProxyPassReverse /application/ http://ip.del.server.qui:8080/application/ Che sostanzialmente fa' la stessa cosa ma in modo un pelo piu' brutale. Inoltre il connector ha anche parecchie altre configurazioni possibili, vedere la documentazione del Connector e' una buona guida.
Non funziona un fico secco!		Se avete aggiunto un'applicazione a TomCat e non riuscite a far funzionare il Connector per tale applicazione ci sono un certo numero di passi da fare per verificare il tutto. Verificate che l'applicazione funzioni da TomCat Che significa, brutalmente, aprite il vostro browser su http://ip.del.server.qui:8080/applicazione/ e verificate che la vostra applicazione funzioni IN TOTO richiamando direttamente TomCat. Se l'applicazione non funziona cosi', non c'e' speranza che funzioni richiamata dal connector. Verificate che JkMount funzioni Se aggiungete una direttiva JkMount e richiamando la 'directory' che dovrebbe essere montata vi arriva un'error 404 da Apache significa che Apache non sta' chiamando TomCat. Distinguere chi sta mandando l'errore e' abbastanza facile. TomCat proclama "Apache Tomcat/versione" nell'ultima linea dell'errore. Se il problema e' nel JkMount, provate per prima cosa ad aggiornare la cache del vostro browser, di tanto in tanto ho notato che il browser non richiama nemmeno il server. Verificate che il JkMount si riferisca ad una applicazione valida Se la vostra applicazione si chiama Applicazione1 e la 'montate' come Applicazione2 vi sono reali possibilita' che non funzioni per niente.