Tomcat. Przewodnik encyklopedyczny. Wydanie II

Tomcat. Przewodnik encyklopedyczny. Wydanie II

-

Livres
314 pages

Description

Poznaj mo?liwo?ci serwera Tomcat!</b></h4></div> <ul><li>Jak dostroi? Tomcat w celu pomiaru i poprawy wydajno?ci?</li><li>Jak wdra?a? aplikacje WWW z serwletami i stronami JSP?</li><li>Jak diagnozowa? problemy z serwerem?</li></ul><p>Tomcat jest kontenerem serwletów Java i serwerem WWW stworzonym przez organizacj? Apacze Software Foundation. Mo?e pe?ni? rol? serwera produkcyjnego o du?ej wydajno?ci, sprawdza si? równie? jako darmowy kontener serwletów i stron JSP z udost?pnionym kodem ?ród?owym. Tomcat mo?e by? zastosowany niezale?nie lub w po??czeniu z innymi serwerami WWW (np. httpd Apache). Doskonale radzi sobie w ka?dego rodzaju ?rodowisku, zapewniaj?c fundament wymagany do praktycznego wykorzystania w Internecie umiej?tno?ci z zakresu technologii Java.</p><p>W ksi??ce "Tomcat. Przewodnik encyklopedyczny" znajdziesz szczegó?owe wyja?nienia, jak korzysta? z tego serwera. Czytaj?c j?, poznasz wszelkie procedury instalacyjne oraz mo?liwo?ci konfigurowania obszarów, ról, u?ytkowników i zasobów JNDI. Nauczysz si?, jak uaktywnia? i wy??cza? funkcj? automatycznego prze?adowywania serwletów, a tak?e wdra?a? aplikacje WWW. Niezb?dne informacje dotycz?ce serwera Tomcat znajd? tu nie tylko programi?ci, ale tak?e administratorzy, webmasterzy i wszyscy, którzy chc? si? dowiedzie? czego? o tym kontenerze serwletów.</p><ul><li>Instalowanie i konfigurowanie Tomcata</li><li>Zarz?dzanie obszarami, rolami i u?ytkownikami</li><li>Uruchamianie i zatrzymywanie serwera</li><li>Kontrolowanie i utrwalanie sesji</li><li>Optymalizowanie wydajno?ci serwera</li><li>Integracja z serwerem WWW Apache</li><li>Wdra?anie rozpakowanego katalogu aplikacji WWW</li><li>Praca z plikami WAR</li><li>Zabezpieczenia serwera Tomcat</li></ul><div align="center"><h4><b>Przewodnik dla wszystkich, którzy chc? u?atwi? sobie prac? z serwerem Tomcat.


Sujets

Informations

Publié par
Ajouté le 05 novembre 2008
Nombre de lectures 125
EAN13 9781457171581
Langue Polish
Signaler un problème
Tomcat: Przewodnik encyklopedyczny

Tomcat: Przewodnik encyklopedyczny

Jason Brittain

Ian F. Darwin

Published by Helion

Książka ta jest dedykowana z głębi serca naszemu synowi Aleksowi i naszej córce Angie.

Jason Brittain

SPECIAL OFFER: Upgrade this ebook with O’Reilly

Click here for more information on this offer!

Please note that upgrade offers are not available from sample content.

Przedmowa

Tomcat ułatwił życie tysiącom programistów używających języka Java™, oferując im darmowe środowisko umożliwiające testowanie i wdrażanie aplikacji WWW. Serwer Tomcat znakomicie sprawdził się w każdego rodzaju środowisku, zapewniając fundament wymagany do praktycznego wykorzystania w internecie zdobytych umiejętności z zakresu technologii Java.

O czym jest książka?

Tomcat jest kontenerem serwletów Java i serwerem WWW stworzonym przez organizację Apache Software Foundation (http://tomcat.apache.org). Oczywiście, serwer WWW to oprogramowanie, które udostępnia strony internetowe w odpowiedzi na żądania wygenerowane na przykład przez użytkownika korzystającego z przeglądarki internetowej. Jednak serwery WWW nie są ograniczone tylko do oferowania statycznych stron HTML. W odpowiedzi na żądania użytkowników mogą one również uruchamiać programy i do przeglądarki odsyłać dynamiczne dane. Jest to aspekt technologii WWW, w przypadku którego serwer Apache Tomcat bardzo dobrze sobie radzi, gdyż zapewnia zarówno serwlety Java, jak i strony JavaServer Pages (a także udostępnia tradycyjne statyczne strony i zewnętrzne programy CGI (Common Gateway Interface) napisane w dowolnym języku programowania). W efekcie w przypadku wielu zastosowań Tomcat jest dobrym kandydatem na serwer WWW (może pełnić rolę serwera produkcyjnego o dużej wydajności). Tomcat jest też bardzo dobrą propozycją, jeśli szuka się darmowego kontenera serwletów i stron JSP z udostępnionym kodem źródłowym (http://opensource.org). Tomcat może być zastosowany niezależnie lub w połączeniu z innymi serwerami WWW, takimi jak httpd Apache.

Książka wyjaśnia, jak korzystać z samego serwera Tomcat. Jeśli Czytelnik szuka szczegółowych informacji i podręczników poświęconych tworzeniu aplikacji WWW, koniecznie musi sięgnąć po książkę Java Servlet Programming napisaną przez Jasona Huntera i Williama Crawforda (wydawnictwo O’Reilly).

Dlaczego całą książkę poświęcono serwerowi Tomcat?

Czy nie można po prostu pobrać Tomcata z witryny internetowej organizacji Apache Software Foundation, a następnie go zainstalować i uruchomić? Cóż, oczywiście można to zrobić i trzeba będzie. Jednak z serwerem Tomcat wiąże się znacznie więcej zadań i zagadnień niż tylko postaranie się o to, żeby się załadował. Z serwera Tomcat uzyska się więcej korzyści, jeśli zrozumie się, jak i dlaczego został napisany. Temu poświęciliśmy Rozdział 1. Po jego lekturze Czytelnik będzie w stanie podejmować lepsze decyzje, które mogą być konieczne podczas instalowania Tomcata. W związku z tym w pozostałej części Rozdział 1. zaprezentowaliśmy procedury instalacyjne i uruchomieniowe.

W Rozdział 2, zaprezentowaliśmy wszystko na temat konfigurowania serwera Tomcat. Wspomnieliśmy o tym, kiedy Tomcata powinno się użyć w roli niezależnego serwera WWW i kontenera serwletów, a kiedy najlepiej zastosować go razem z serwerem httpd Apache. Dalej wyjaśniliśmy, jak konfigurować obszary, role, użytkowników, sesje serwletowe i zasoby JNDI, z uwzględnieniem obiektów DataSource interfejsu JDBC. Pokazaliśmy, w jaki sposób uaktywniać i wyłączać funkcję automatycznego przeładowywania serwletów, jak przenosić katalog webapps, a także jak mapować domowe katalogi użytkowników w celu uzyskania dostępu do nich za pośrednictwem Tomcata. Dalej zajęliśmy się włączaniem i wyłączaniem przykładowych aplikacji WWW oraz uaktywnianiem w serwerze Tomcat obsługi skryptów CGI. Na końcu Rozdział 2. zaprezentowaliśmy administracyjną aplikację WWW Tomcata, która umożliwia konfigurowanie go przy użyciu przeglądarki internetowej.

Po zainstalowaniu i skonfigurowaniu serwera Tomcat w żądany sposób można zacząć poszerzanie wiedzy na temat aplikacji WWW bazujących na serwletach i stronach JSP, a także dowiedzieć się, jak wdrażać je w obrębie Tomcata. W Rozdział 3, przedstawiliśmy strukturę aplikacji WWW, metodę wdrażania takiej aplikacji, jak również wybranych serwletów i stron JSP. W dalszej części rozdziału omówiliśmy proces tworzenia plików archiwum aplikacji i sposoby wdrażania ich. Aby czynności nie były zbyt nużące, dokonaliśmy przeglądu metod automatyzowania procesu wdrażania aplikacji WWW (kopiowanie, użycie wbudowanej aplikacji zarządzającej i zastosowanie narzędzia budującego Jakarta Ant).

Gdy serwer Tomcat udostępnia już aplikacje WWW, można przeprowadzić działania mające na celu optymalizację wydajności. W Rozdział 4, pokazano, jak mierzyć i poprawiać wydajność serwera Tomcat. Zajęliśmy się dostosowywaniem liczby wątków procesora, a także kwestiami wydajności wirtualnej maszyny Java i systemu operacyjnego, które dotyczą Tomcata. Omówiliśmy wyłączanie funkcji sprawdzania adresów DNS i pokazaliśmy, jak przyspieszyć strony JSP. Rozdział 4. zakończyliśmy dyskusją dotyczącą wpływu planowania obciążenia na wydajność.

Tomcat działa jako zupełnie niezależny serwer WWW. Obsługuje statyczne strony WWW, zewnętrzne skrypty CGI i wiele innych składników powiązanych z witryną internetową. Jednak mocną stroną Tomcata, powodem jego istnienia, jest uzyskanie statusu najlepszego silnika obsługującego serwlety i strony JSP. Są rzeczy, które serwer Tomcat wykonuje najlepiej. Jeśli korzysta się już z serwera httpd Apache i nie zamierza się zmieniać wszystkiego od razu, w Rozdział 5, omówiono zastosowanie Tomcata razem z serwerem httpd Apache, a także zaprezentowano kilka metod umiejscawiania Tomcata „przed” lub „za” instalacją serwera httpd Apache.

Niezależnie od tego, czy tworzy się sklep internetowy, listę wysyłkową lub własną witrynę WWW, po nawiązaniu połączenia z internetem witryna stanie się dostępna dla wielu osób, w tym dziwaków, którzy uważają, że nie jest niczym złym wykorzystywanie luk w zabezpieczeniach oprogramowania serwerowego dla rozrywki i (lub) zysku. Ponieważ bezpieczeństwo jest istotną kwestią, Rozdział 6, poświęciliśmy temu, jak utrzymać na uwięzi sieciowych złoczyńców.

W Rozdział 7, zaprezentowaliśmy pliki konfiguracyjne Tomcata, server.xml i web.xml, a także pliki tomcat-users.xml, catalina.policy, catalina.properties i context.xml. Każdy z tych plików można modyfikować w celu kontrolowania sposobu działania Tomcata.

Gdy coś złego dzieje się z serwerem Tomcat lub aplikacją WWW, należy zajrzeć do Rozdział 8, w którym przedstawiono kilka metod diagnozowania problemu. Pokazaliśmy, czego szukać w plikach dzienników, jak przeglądarka internetowa współpracuje z serwerem WWW Tomcat podczas przetwarzania żądania, a także jak uzyskać szczegółowe informacje o konkretnym żądaniu i co zrobić, jeśli Tomcat po prostu nie chce zakończyć pracy pomimo wyraźnego żądania.

Ponieważ nie każdy zamierza korzystać z wcześniej utworzonej binarnej wersji Tomcata, w Rozdział 9, wyjaśniliśmy, jak samemu skompilować kod źródłowy serwera Tomcat. Krok po kroku omówiliśmy proces instalowania narzędzia budującego Apache Ant, pobierania niezbędnych dodatkowych bibliotek i tworzenia binariów Tomcata.

Jeżeli do witryny trafia liczba żądań większa od tej, która może być obsłużona przez pojedynczy serwer Tomcat, lub oczekuje się, że witryna będzie nadal przetwarzać żądania, nawet pomimo tego, że jeden z serwerów uległ awarii, może być konieczne uruchomienie witryny na więcej niż jednym serwerze Tomcat lub Apache bądź kombinacji tych serwerów. Czasami jedynym rozwiązaniem jest zastosowanie większej ilości sprzętu. W Rozdział 10, przedstawiono kilka wariantów jednoczesnego uruchamiania dwóch lub większej liczby kontenerów serwletów Tomcat w celu zapewnienia zarówno odporności na awarie, jak i większej skalowalności. Dodatkowo omówiono zalety i wady różnych rozwiązań klastrowych.

W Rozdział 11, dokonaliśmy przeglądu zasobów związanych z projektem open source rozwijającym serwer Tomcat (w tym między innymi dokumentacji, list wysyłkowych i innych witryn internetowych). Są to wartościowe zasoby pozwalające rozwiązać wszelkie problemy, które mogą pojawić się w przypadku przyszłych wersji Tomcata. Zasoby te mogą też pomóc w większym zaangażowaniu się w rozwijanie Tomcata (jeśli jest to jeden z celów, jakie Czytelnik sobie założył).

Zależnie od używanego systemu operacyjnego, instalowanie środowiska Java może nie być tak proste jak może się wydawać. W celu zapewnienia, że serwer Tomcat będzie dobrze działał na komputerze będącym serwerem, w Dodatek A, krok po kroku pokazaliśmy, jak zainstalować środowisko uruchomieniowe Java, i objaśniliśmy kilka godnych uwagi kwestii związanych z tym środowiskiem.

Dla kogo jest ta książka?

Książkę napisano z myślą o każdym, kto chce dowiedzieć się czegoś o kontenerze serwletów Tomcat. Nie trzeba być programistą, żeby korzystać z Tomcata lub tej książki. Jak wspomniano wcześniej, wszystko, co ma związek z programowaniem w języku Java, zostało zawarte wewnątrz serwletów lub innych składników. Można być administratorem systemów lub sieci, który zamierza uruchomić niewielką i prostą witrynę WWW. Można być doświadczonym webmasterem używającym serwera WWW Apache, który w ramach większej witryny musi uaktywniać jeden lub większą liczbę serwletów. Czytelnik może być programistą, który w języku Java tworzy składniki WWW i chce szybko być na bieżąco w zakresie zastosowania Tomcata w roli serwera aplikacji WWW w fazie projektowej i produkcyjnej. Być może Czytelnik używa jednego z wielu serwerów Java EE, w skład których wchodzi Tomcat jako kontener WWW. Z dowolnego z powyższych powodów dla każdego innego typu odbiorcy książka stanowi znakomite wprowadzenie do serwera Tomcat.

Konwencje zastosowane w książce

W książce użyto następujących konwencji typograficznych:

Kursywa

Przy użyciu tego stylu są wyróżnione nazwy plików, adresy URL i nowe terminy.

Tekst o stałej szerokości

Styl ten wyróżnia elementy XML, klasy Java i polecenia do wykonania.

Pogrubiona kursywa

Tym stylem są wyróżnione łańcuchy, w miejsce których należy wstawić rzeczywistą nazwę.

Kursywa o stałej szerokości

Za pomocą tego stylu są wyróżniane łańcuchy zawarte w wierszach poleceń, w miejsce których należy wstawić rzeczywistą nazwę.

Listing

Stylem tym są identyfikowane przykładowe kody i wyniki wygenerowane przez polecenia.

Pogrubiony listing

Przy użyciu tego stylu w przykładowych kodach wyróżnia się wiersze wymagające szczególnej uwagi.

Podpowiedź

Ikona oznacza wskazówkę, sugestię lub ogólną uwagę.

Ostrzeżenie

Ikona symbolizuje ostrzeżenie.

Ponadto litery SRV ze znajdującymi się za nimi liczbami oddzielonymi kropkami odwołują się do określonej sekcji specyfikacji Servlet Specification w wersji 2.5. Przykładowo SRV.6.5 odnosi się do podsekcji 5. sekcji 6. tej specyfikacji. Z kolei litery JSP z liczbami oddzielonymi kropkami dotyczą wybranej sekcji specyfikacji JSP. Obie specyfikacje są dostępne do pobrania odpowiednio pod adresami http://java.sun.com/products/servlet i http://java.sun.com/products/jsp.

Zastosowanie przykładowych kodów

Książka ma za zadanie pomóc w wykonaniu pracy. Zwykle kod zamieszczony w książce można wykorzystać we własnych programach i dokumentacji. Jeśli nie powiela się znacznej ilości kodu, nie trzeba kontaktować się z wydawnictwem, żeby uzyskać zgodę. Przykładowo nie będzie ona potrzebna, gdy wykorzysta się kilka bloków kodu znajdującego się w książce. Sprzedaż lub dystrybucja dysku CD-ROM z przykładami z książki wymaga pozwolenia. Nie jest ono konieczne w przypadku cytowania w odpowiedzi na pytanie fragmentów książki lub przykładowego kodu. Zgody wymaga uwzględnienie w dokumentacji własnego produktu znacznej ilości przykładowego kodu zawartego w książce.

Przykładowe kody są dostępne do pobrania pod adresem ftp://ftp.helion.pl/przyklady/tomcat.zip.

Podziękowania

Przede wszystkim podziękowania dla Jamesa Duncana Davidsona i firmy Sun Microsystems za ofiarowanie nam serwera Tomcat. James zrobił wszystko, co w jego mocy, a nawet więcej, żeby napisać serwer i określić szczegóły dotyczące tego, na jakich zasadach serwer mógł się stać oprogramowaniem open source. Firma Sun Microsystems wspierała pionierskie działania Jamesa i mocno zaangażowała się w rozwój Tomcata od momentu przekazania go organizacji Apache Software Foundation.

Ogromne wyrazy wdzięczności dla Simona St.Laurenta, redaktora drugiej edycji książki (po Brett McLaughlin), którego cierpliwość do mnie (gdy czas poświęcałem na poszukiwanie i jasne udokumentowanie odpowiedzi na pytania pojawiające się podczas pisania książki) przerosła moje oczekiwania. Dziękuję mu również za okazywanie nieustającej wiary we mnie.

Następne wielkie wyrazy wdzięczności dla Brett McLaughlin, która redagowała pierwszą edycję książki i w początkowych miesiącach realizowania projektu była redaktorem drugiego wydania. Brett przekazała mi ogromną ilość drobnych sugestii mających na celu ulepszenie książki. Kilkakrotnie rozmawiała z nami na temat reorganizacji nieuporządkowanego materiału do ostatecznej postaci (taką mamy nadzieję), którą Czytelnik ma przed sobą. Dzięki, Brett!

Paula Ferguson widziała pierwsze wydanie książki w jej początkowej fazie, a następnie przekazała pałeczkę Brett McLaughlin. Dzięki, Paula!

Projekty open source po prostu nie są tym samym bez związanej z nimi aktywnej społeczności. Wierzymy, że serwer Tomcat nie osiągnąłby tak wiele w tak krótkim czasie bez wsparcia organizacji Apache Software Foundation i jej członków. Dziękujemy im za ciężką pracę, serwery i przepustowość.

Jason Hunter, autor Java Servlet Programming (wydawnictwo O’Reilly), bardzo dokładnie zapoznał się z roboczymi wersjami pierwszej edycji naszej książki i zaproponował wiele ulepszeń. Szczególne podziękowania dla Ciebie, Jason.

Podziękowania Jasona Brittaina

Wielkie dzięki dla mojej żony Carminy za opiekowanie się naszymi pociechami, gdy przez ponad dwa lata pisałem książkę. Dzięki, Cutie, za wszelką pomoc, którą mi ofiarowałaś, a także za to, że byłaś dla mnie inspiracją. Kocham Cię bardzo i zawsze będę Cię kochał!

Podziękowania dla Jamesa Duncana Davidsona i Jasona Huntera, którzy mieli znakomitą wizję pierwszego wydania książki i dołożyli wszelkich starań, by ją zrealizować.

Chciałbym osobiście podziękować Simonowi St. Laurentowi za wsparcie, jakiego mi udzielał podczas pracy nad książką. Poziom jej szczegółowości i przejrzystość pokazują, jak bardzo Simon starał się, żeby mieć pewność, że będę miał czas na pisanie książki w ten sposób. Dzięki, Simon!

Wyrazy wdzięczności kieruję również do Iana Darwina, współautora pierwszego wydania książki. Napisał na temat Tomcata sporą ilość wartościowego i niemal wiecznego materiału, który pozostał w drugim wydaniu.

Akbar Ansari to osoba, która bezpośrednio zaangażowała się w prace nad większością treści drugiego wydania książki (poza Simonem St.Laurentem, redaktorem większej części projektu). Akbar dostarczył mi wiele zrzutów ekranów, których utworzenie zajęłoby mi niezliczone dodatkowe godziny, kilka razy wykonał wykres danych pomiarowych, przeprowadził korektę części mojego tekstu i przekazał swoje uwagi. Co najważniejsze, mobilizował mnie do pracy nad książką. Dzięki, Akbar, za tak wielką pomoc i autentyczne zainteresowanie!

Dziękuję również Jamie Madden za pełnienie obowiązków korektora technicznego drugiego wydania.

Bart Busschots i Jamie Madden są autorami fragmentów książki dotyczących systemu Mac OS X. Znakomita, pionierska praca! Dzięki!

Sebastien Diotte zaimplementował oryginalną wersję 5.5+ składnika BadInputValve. Sean McCauliff przekazał uwagi na temat tekstowych dziwolągów w niektórych rozdziałach, a Mike Miller pokazał mi istotną regułę dotyczącą przemapowywania portów narzędzia ipfilter systemu FreeBSD. Podziękowania dla Marka Petrovica za rozmowy ze mną na temat narzędzia SecurityManager i za napisanie artykułu o automatycznym wykrywaniu zasad zabezpieczeń. Wyrazy wdzięczności dla Nicholasa Schuetza za stworzenie i utrzymywanie kanału IRC #tomcat na serwerze irc.freenode.net (pomógł niezliczonej liczbie użytkowników Tomcata). Podziękowania dla Philipa Mortona, Roberta Brindamoura i Toma Duggina za usunięcie ze składnika BadInputValve błędu związanego ze skalowalnością. Dziękuję Williamowi Osmondowi (choć w moich notatkach zapomniałem zapisać, w czym mi pomogłeś, wiem, że to zrobiłeś; dzięki!), Fabrice Bellardowi i innym osobom za napisanie oprogramowania QEMU, dzięki któremu mogłem uruchomić tak wiele różnych systemów operacyjnych, o których pisałem. Podziękowania dla Jasona Gablera za pokazanie mi przeglądarki sventon.

Wyrazy wdzięczności kieruję do moich współpracowników i przyjaciół z centrum badawczego Ames NASA i misji NASA Kepler Space Telescope (http://kepler.nasa.gov) za umożliwienie mi wzięcia w niej udziału. Ostatecznie nasze oprogramowanie odkryje wiele nowych nadających się do zasiedlenia światów, które nigdy wcześniej nie zostały znalezione przez gatunek ludzki.

Chcę również podziękować Rodneyowi Joffe (wcześniej pracował w firmie Genuity) za mnóstwo wiary we mnie na początku mojej kariery, a także za wprowadzenie mnie w 1996 r. w takie zagadnienia, jak wysoka dostępność, równoważenie obciążenia i odporność na awarie. Podziękowania dla Davida Jemmetta (wcześniej był pracownikiem firmy GoodNet) nie tylko za danie mi pierwszej dużej szansy sprawdzenia się w roli inżyniera i administratora systemów, ale też za umożliwienie mi w połowie 1995 r. rozpoczęcia projektowania dynamicznych aplikacji WWW. Jestem wdzięczny każdemu z Was!

Chciałbym też podziękować Theronowi Tisonowi, który jest najbardziej troskliwą osobą, jaka przy mnie była, gdy dorastałem. Był podporą mojej wiary, która pozwoliła mi osiągnąć niemal wszystkie z założonych celów. Dziękuję Theronowi za pomaganie mi przez tak wiele trudnych lat.

Podziękowania Iana Darwina

Mike Loukides zachęcił mnie do napisania książki dla wydawnictwa O’Reilly, gdy po sukcesie książki Java Cookbook próbowało przekonać mnie do siebie konkurencyjne wydawnictwo.

Kevin Bedell dokładnie przeczytał cały rękopis i zasugerował mi wiele ulepszeń (jak również zwrócił uwagę na kilka błędów i niedopatrzeń). Dzięki, Kevin.

Przez lata od Chada Darby dowiedziałem się wiele na temat technologii JavaServer Pages. Chad jest twórcą kursu Learning Tree (http://www.learningtree.com) poświęconego serwletom i stronom JSP. Chad pomógł mi również, sprawdzając rękopis.

Oczywiście, dziękuję Betty, kobiecie mojego życia, i naszym dzieciom, Benjaminowi, Andy’emu i Margaret. Dzięki za wsparcie i miniony czas.

Szczególnie serdeczne wyrazy wdzięczności dla Jasona za przejęcie moich obowiązków i wykonanie wszystkich poprawek w drugim wydaniu książki, gdy stwierdziłem, że mam coś ważniejszego do zrobienia. Wyjątkowo duży plus dla Ciebie, Jason, za trzymanie się tego zadania do końca pomimo potrzeb Twojej powiększającej się rodziny!

Rozdział 1. Tomcat — wprowadzenie

Ponieważ serwer Tomcat napisano w języku Java, niektórzy przyjmują, że trzeba być ekspertem od Javy, żeby móc korzystać z tego serwera. Nie jest to prawdą. Choć wymagana jest znajomość Javy do wprowadzania zmian w wewnętrznych mechanizmach Tomcata lub w celu pisania własnych serwletów, nie trzeba w ogóle znać Javy, żeby używać Tomcata bądź tworzyć lub utrzymywać wiele stron JSP (JavaServer Pages). Można dysponować stronami JSP, które stosują składniki JavaBean i niestandardowe znaczniki JSP. W obu przypadkach po prostu używa się składników Javy przygotowanych dla użytkownika przez projektanta.

W tym rozdziale wyjaśniono, jak zainstalować serwer Tomcat, uruchomić go i przetestować, żeby mieć pewność, że poprawnie funkcjonuje.

Podpowiedź

Choć w czasie pisania książki było dostępnych kilka produkcyjnych wersji Tomcata, szczególnie namawiamy do zastosowania najnowszej stabilnej wersji z gałęzi 6.0 lub dowolnej najbardziej aktualnej stabilnej wersji serwera, która będzie dostępna w czasie czytania książki. Na stronie internetowej Apache Tomcat (http://tomcat.apache.org) można znaleźć najnowszą stabilną wersję. Z myślą o wersjach 5.5 i 6.0 serwera Tomcat zamieszczono w książce wystarczającą liczbę objaśnień dotyczących ogólnych zagadnień z zakresu działania Tomcata. Ponadto bardzo szczegółowo wyjaśniono, jak korzystać z tych popularnych wersji Tomcata.

Instalowanie Tomcata

Można na kilka sposobów skonfigurować i uruchomić serwer Tomcat. Najszybszy z nich polega na pobraniu i uruchomieniu skompilowanych binariów. Tomcat został napisany w języku Java. Oznacza to, że przed instalowaniem lub testowaniem Tomcata trzeba dysponować aktualnym i kompletnym środowiskiem uruchomieniowym Java. Aby mieć pewność, że poprawnie zainstalowano to środowisko, należy zapoznać się z dodatkiem A. Nie wolno rezygnować z tego kroku, gdyż jest ważniejszy, niż mogłoby się wydawać!

Jedną z zalet projektów open source jest to, że programiści znajdują i usuwają błędy, a także wprowadzają w oprogramowaniu ulepszenia. Jeśli Czytelnik nie jest programistą, ponowne kompilowanie kodu źródłowego serwera Tomcat da znikomą lub żadną korzyść, ponieważ w tym przypadku nie będzie się zainteresowanym takim poziomem interakcji. Jeżeli Czytelnik nie ma doświadczenia jako projektant składników serwera Tomcat, próba kompilowania i stosowania własnych binariów Tomcata w rzeczywistości może spowodować problemy. Wynika to stąd, że dość łatwo można utworzyć binaria Tomcata w sposób, który sprawi, że bez wiedzy użytkownika zostaną wyłączone istotne funkcje. Aby szybko przejść do rzeczy, powinno się pobrać oficjalny pakiet binarny serwera Tomcat przeznaczony dla używanego systemu.

Podpowiedź

W celu uzyskania wskazówek dotyczących kompilowania źródeł należy zajrzeć do Rozdział 9.

Istnieją dwa poziomy pakietów. Organizacja Apache Software Foundation udostępnia binaria w postaci podstawowych wersji i codziennych kompilacji. Inne organizacje umieszczają te dane w pakietach RPM i innego typu zestawach instalacyjnych dla systemu Linux, w pakietach dla systemu BSD itd. Najlepsza metoda instalowania Tomcata zależy od używanego systemu. W książce zaprezentowano proces instalacji Tomcata w systemach Linux, Solaris, Windows, Mac OS X i FreeBSD.

Tomcat 6 wymaga środowiska uruchomieniowego Java w wersji 1.5 lub nowszej (dział marketingu firmy Sun stosuje termin Java 5). Jednakże ze względu na dodatkowe funkcje, poprawki i ulepszenia zwiększające wydajność sugerujemy uruchomienie Tomcata w środowisku wirtualnej maszyny Java 1.6 lub nowszym.

Instalowanie Tomcata w systemie Linux

W przypadku systemu Linux serwer Tomcat jest dostępny w co najmniej dwóch różnych wersjach binarnych. Użytkownicy tego systemu mają do wyboru następujące opcje:

Wieloplatformowe wersje binarne

Niezależnie od używanej dystrybucji Linuksa można pobrać z witryny internetowej serwera Apache dowolną z binarnych wersji Tomcata, a następnie zainstalować go i uruchomić. Te wersje mają postać plików archiwów o rozszerzeniach .tar.gz i .zip. Serwer Tomcat można zainstalować w dowolnym wybranym katalogu i przy użyciu każdego identyfikatora użytkownika istniejącego w systemie. Jednak tego typu instalacja nie jest monitorowana przez żaden menedżer pakietów. W związku z tym później trudniejsze będzie uaktualnienie lub odinstalowanie. Ponadto takie wersje instalacyjne nie zawierają skryptu init umożliwiającego integrację z procesami uruchamiania i zamykania systemu.

Macierzysty pakiet dystrybucji

Jeśli korzysta się z systemu Fedora lub Red Hat Linux (bądź innej odmiany Linuksa używającej menedżera pakietów dystrybucji Red Hat, takiej jak SUSE lub Mandriva), można pobrać binarny pakiet RPM serwera Tomcat. Pakiet ten pozwala w prosty sposób przeprowadzić proces odinstalowania i aktualizacji za pośrednictwem menedżera Red Hat Package Manager. Oprócz tego pakiet RPM uwzględnia skrypt init, który umożliwia zatrzymywanie, uruchamianie i restartowanie Tomcata z poziomu wiersza poleceń i podczas ponownego ładowania systemu. Wadą tej metody jest konieczność zainstalowania pakietu RPM serwera Tomcat z uprawnieniami superużytkownika. Gdy pisano książkę, do wyboru były przynajmniej dwie wersje pakietu RPM, oferujące różne funkcje.

Trzeba jednak mieć świadomość tego, że Linux to tylko jądro systemu operacyjnego, a kompletny system operacyjny to dystrybucja. Obecnie istnieje wiele różnych dystrybucji Linuksa. Niektóre z nich to Fedora, Red Hat, Ubuntu, Mandriva, Gentoo i Debian. Choć dowolne dwie dystrybucje Linuksa raczej są do siebie podobne, występuje również wystarczająco dużo różnic, które utrudniają programistom utworzenie jednego skryptu z powodzeniem działającego w obu dystrybucjach. Ponadto każda dystrybucja Linuksa może głównie używać odmiennego macierzystego menedżera pakietów. A zatem każda wersja dystrybucji może zmienić w systemie operacyjnym dowolną liczbę rzeczy, włącznie z Javą[1] i Tomcatem. Częstą sytuacją jest dołączenie do dystrybucji Linuksa oprogramowania napisanego w języku Java, które nie działa, gdyż pakiet tego programu obecny w dystrybucji jest w zawoalowany sposób uszkodzony. Dystrybucje mają też tendencje do zawierania starych wersji Tomcata, które są niestabilne lub nie za bardzo nadają się do obsługi witryny WWW w porównaniu z najnowszą dostępną stabilną wersją. Z tych powodów prawie zawsze najlepiej zainstalować aktualną stabilną wersję serwera Tomcat, którą uzyskano we własnym zakresie.

Ponieważ istnieje tak wiele dystrybucji Linuksa i różnią się one między sobą w znaczącym stopniu, podawanie dokładnych instrukcji dotyczących najlepszego wariantu instalacji Tomcata dla każdej wersji poszczególnych dystrybucji systemu Linux wykracza poza zakres książki. Na szczęście popularne dystrybucje Linuksa są na tyle do siebie podobne, że w celu zainstalowania Tomcata z archiwum wersji binarnej pobranej z witryny Apache Tomcat wystarczy postępować zgodnie z instrukcjami bardziej podstawowego procesu instalacji.

Jeżeli korzysta się z dystrybucji linuksowej Fedora lub Red Hat, do wyboru będzie więcej niż jedna odmiana pakietu RPM serwera Tomcat. Oto one:

Pakiet RPM dołączony do książki

Jest to w pełni przenośny pakiet RPM, który z łatwością może być ponownie skompilowany za pośrednictwem niestandardowego pliku kompilacji ant. Zamiast kompilowania samego serwera Tomcat plik ten tworzy pakiet binariów Tomcata w wersji 6. dla oficjalnej wieloplatformowej wersji oprogramowania Apache. Ponieważ ten pakiet RPM nie zależy od żadnego innego pakietu RPM, możemy zainstalować go samodzielnie. Jednakże pakiet trzeba skonfigurować, tak żeby używał zainstalowanego środowiska uruchomieniowego Java (JDK lub JRE). W Dodatek E można znaleźć pełne zestawienie kodu źródłowego skryptów pakietu RPM.

Pakiet RPM dostępny na stronie internetowej JPackage.org

Jest to nieprzenośny pakiet RPM, który serwer Tomcat instaluje w katalogu /var. Tomcat jest ponownie kompilowany z kodu źródłowego, a następnie są tworzone wieloplatformowe binaria. Ten pakiet RPM zależy od wielu innych pakietów RPM (każdy z nich może jeszcze wymagać kolejnych pakietów) z witryny JPackage.org i musi zostać zainstalowany wraz z powiązanymi pakietami RPM. W czasie, gdy powstawała książka, witryna JPackage.org nie dysponowała pakietem RPM serwera Tomcat w wersji 6.0, a jedynie 5.5.

Każdy z tych pakietów RPM zawiera skrypty służące do instalowania, odinstalowywania i aktualizowania Tomcata, a także skrypty umożliwiające dynamiczną integrację z systemem operacyjnym. Namawiamy do wypróbowania najpierw pakietu dodanego do książki.

Jeśli używa się dystrybucji Gentoo Linux, dostępna jest kompilacja serwera Tomcat 6, którą można zainstalować i stosować. W tym przypadku należy zapoznać się z przewodnikiem Williama L. Thomsona Jr. znajdującym się pod adresem http://www.gentoo.org/proj/en/java/tomcat6-guide.xml. Ponadto należy wyświetlić stronę Tomcat Gentoo ebuild witryny Gentoo Wiki (http://gentoo-wiki.com/Tomcat_Gentoo_ebuild). Oprócz tej kompilacji do książki dołączono pakiet RPM przeznaczony do instalacji i uruchomienia w systemie Gentoo Linux (wcześniej trzeba jedynie zainstalować narzędzie rpm).

Instalowanie Tomcata z wieloplatformowej binarnej wersji oprogramowania Apache

Ze względów bezpieczeństwa raczej powinno się utworzyć użytkownika tomcat z niewielkimi przywilejami i korzystając z niego, uruchomić serwer Tomcat. Sugerujemy ustawienie dla tego użytkownika powłoki logowania /sbin/nologin i zablokowanie hasła, tak żeby nie można było go odgadnąć. Poza tym prawdopodobnie dobrym pomysłem będzie przypisanie użytkownikowi tomcat podstawowej grupy nobody lub innej grupy z podobnie małymi uprawnieniami. Po zalogowaniu jako superużytkownik trzeba będzie w tym celu wykonać następujące polecenie:

# useradd -g 46 -s /sbin/nologin -d /opt/tomcat/temp tomcat

Jeśli nie dysponuje się dostępem do konta superużytkownika, serwer Tomcat można uruchomić, używając własnego konta. Jednak trzeba wiedzieć, że w tym przypadku zdalnie mogą zostać wykorzystane wszelkie luki w zabezpieczeniach Tomcata (są one wyjątkowo rzadkie).

Pora pobrać archiwum wersji z witryny binarnych wersji oprogramowania Apache (http://tomcat.apache.org/download-60.cgi). Powinno się pobrać najnowszą stabilną wersję wymienioną na stronie internetowej serwera Tomcat (http://tomcat.apache.org).

Ostrzeżenie

Jeśli nawet zamierza się zainstalować tylko podzbiór plików archiwum wybranej wersji Tomcata, powinno się pobrać wszystkie pliki archiwum dla tej wersji, na wypadek gdyby później okazały się potrzebne. Choć organizacja Apache Software Foundation przechowuje archiwalne wersje Tomcata, również samemu powinno się zapisywać własne kopie. Jeżeli Czytelnik jest zaawansowanym użytkownikiem Tomcata, prawdopodobnie powinien też pobrać archiwa kodów źródłowych używanej wersji i ich kopie magazynować. Dzięki temu możliwe będzie wykrycie wszelkich potencjalnych błędów, które mogą wystąpić w wybranej wersji.

Główne binarne archiwum wersji Tomcata należy poddać dekompresji. Jeśli na przykład pobrano archiwum apache-tomcat-6.0.14.tar.gz, należy je rozpakować w dowolnym miejscu, w którym mają się znaleźć pliki Tomcata.

$ cd $HOME
$ tar zxvf apache-tomcat-6.0.14.tar.gz

Przed kontynuowaniem działań przez chwilę powinno się przejrzeć plik tekstowy RELEASE-NOTES, znajdujący się w głównym katalogu nowej instalacji Tomcata. W pliku są ważne informacje dla każdego, kto instaluje Tomcata. W pliku można znaleźć szczegóły dotyczące pobranej wersji. Bardzo ważne jest, żeby przed rozpoczęciem instalacji przeczytać dostępny w internecie dziennik zmian dotyczący wybranej wersji serwera Tomcat. Przykładowo sieciowy dziennik zmian dotyczący serwera Tomcat 6.0 jest dostępny pod adresem http://tomcat.apache.org/tomcat-6.0-doc/changelog.html. Niezależnie od instalowanej i używanej wersji Tomcata powinno się sprawdzić błędy wyszczególnione w dzienniku zmian, ponieważ błędy obecne w stosowanej wersji są usuwane w nowszych wersjach Tomcata i w dzienniku pojawią się w sekcji tych wersji.

Choć środowisko uruchomieniowe Java 1.5.x działa świetnie z serwerem Tomcat 6, zaleca się użycie środowiska Java 1.6.x.

Jeżeli serwer Tomcat uruchomi się z uprawnieniami użytkownika tomcat (lub dowolnego użytkownika innego niż zalogowany), pliki należy zainstalować tak, żeby użytkownik ten mógł odczytywać je i zapisywać. Po rozpakowaniu archiwów plików Tomcata trzeba ustawić uprawnienia tak, aby użytkownik tomcat dysponował uprawnieniami odczytu i zapisu. Aby zrobić to dla innego konta użytkownika, trzeba ponownie uzyskać dostęp do konta superużytkownika. Z poziomu powłoki należy wykonać następujące polecenie:

# chown -R tomcat apache-tomcat-6.0.14

Tomcat powinien być gotowy do uruchomienia, choć po zrestartowaniu systemu nie zostanie ponownie uruchomiony. Aby dowiedzieć się, jak uaktywnić serwer Tomcat w czasie ładowania komputera, należy zapoznać się z podrozdziałem „Automatyczne uruchamianie”, znajdującym się w dalszej części rozdziału.

Instalowanie Tomcata z linuksowych pakietów RPM dołączonych do książki

Do książki dodano przykładowy pakiet RPM produkcyjnego serwera Tomcat dla systemu Linux (w Dodatek E zamieszczono kod źródłowy). Pakiet ten nie tylko pozwala w elegancki sposób zainstalować i uruchomić Tomcata w systemie Linux, ale też jest przykładem tego, jak można skompilować własny niestandardowy pakiet RPM serwera Tomcat.

W pierwszej kolejności trzeba zainstalować narzędzie Apache Ant (http://ant.apache.org) w wersji 1.6.2 lub nowszej (jednak nie wersji 1.6.4, która została zaniechana). Preferowana jest wersja 1.7.x lub nowsza. Musi być możliwe użycie tego narzędzia z poziomu powłoki. Oto przykład:

# ant -version
Apache Ant version 1.7.0 compiled on December 13 2006

W powłoce musi być również dostępny program rpmbuild. W dystrybucjach Fedora i Red Hat jest to składnik pakietu RPM o nazwie rpm-build. Konieczne jest zastosowanie wersji 4.2.1 lub nowszej (wersja 4.2.0 dodana do systemu Red Hat 9 zawiera błąd, który uniemożliwia programowi rpmbuild poprawne funkcjonowanie; jednak wersja ta staje się przestarzała). Gdy tylko sprawdzi się, że program jest zainstalowany, z powodzeniem można wykonać polecenie rpmbuild.

# rpmbuild --version
RPM version 4.3.2

Archiwum z przykładami dodanymi do książki można pobrać pod adresem ftp://ftp.helion.pl/przyklady/tomcat.zip.

Archiwum należy rozpakować przy użyciu poniższego polecenia.

$ unzip tomcatbook-examples-2.0.zip

Za pomocą następującego polecenia należy przejść do katalogu tomcat-package:

$ cd tomcatbook-examples/tomcat-package

Ze strony internetowej znajdującej się pod adresem http://tomcat.apache.org/download-60.cgi należy pobrać binarne archiwa wersji. Powinno się pobrać najnowszą stabilną wersję wyszczególnioną na stronie internetowej serwera Tomcat (http://tomcat.apache.org). Dla wybranej wersji Tomcata należy pobrać wszystkie pliki archiwum z rozszerzeniem .tar.gz.

Wszystkie pliki binarnego archiwum wersji serwera Tomcat należy przenieść do katalogu tomcatbook-examples/tomcat-package/, żeby mogły być dołączone do zestawu pakietów RPM, które zostaną utworzone.

# cp apache-tomcat-6.0.14*.tar.gz tomcatbook-examples/tomcat-package/

W celu uwzględnienia konfiguracji komputerów, na których zostaną wdrożone pakiety RPM serwera Tomcata, należy zmodyfikować plik conf/tomcat-env.sh. Jako minimum powinno się sprawdzić, czy JAVA_HOME jest bezwzględną ścieżką systemu plików identyfikującą wirtualną maszynę Java w wersji 1.5 lub 1.6 (JDK lub JRE).

Dalej należy uruchomić narzędzie ant, żeby skompilować zestaw pakietów RPM serwera Tomcat 6.

$ ant

Polecenie to powinno utworzyć pakiety RPM serwera Tomcat. Po zakończeniu kompilacji pakiety będą w katalogu dist/.

# ls dist/
tomcat-6.0.14-0.noarch.rpm  tomcat-6.0.14-0-src.tar.gz
tomcat-6.0.14-0.src.rpm     tomcat-6.0.14-0.tar.gz

Proces kompilowania pakietów RPM serwera Tomcat tworzy również źródłowy pakiet RPM[2], a także dla wygody archiwum .tar.gz pakietu RPM.

Pakiet RPM należy skopiować na komputer lub komputery, dla których zamierza się przeprowadzić instalację.

Będąc gotowym do instalacji pakietu RPM, można wybrać jedną z dwóch następujących możliwości:

  • instalacja pakietu w domyślnej lokalizacji określanej przez ścieżkę /opt/tomcat,

  • instalacja pakietu, a następnie przeniesienie danych w żądane miejsce.

Pierwszy wariant instalacji bazuje na następującym poleceniu:

# rpm -ivh tomcat-6.0.14-0.noarch.rpm
Preparing...                ########################################### [100%]
   1:tomcat                 ########################################### [100%]

Oto błąd:

error: Failed dependencies:
         /bin/sh is needed by tomcat-6.0.14-0.noarch

Błąd ten zwykle występuje w systemach operacyjnych, w których nie jest używany menedżer pakietów RPM, a pakiet RPM Tomcata zainstalowano, gdy baza takiego menedżera była pusta (informację o braku pakietów w bazie danych podaje interpreter /bin/sh). Do czegoś takiego może dojść na przykład wtedy, gdy po zainstalowaniu programu rpm pakiet RPM serwera Tomcat instaluje się w systemie operacyjnym Debian Linux.

Za pomocą poniższego polecenia należy ponownie przeprowadzić instalację.

# rpm -ivh --nodeps tomcat-6.0.14-0.noarch.rpm

Jeżeli pojawią się poniższe ostrzeżenia dotyczące użytkowników i grup, trzeba będzie ręcznie za pomocą narzędzi adduser i addgroup utworzyć użytkownika tomcat i grupę nobody.

warning: user tomcat does not exist - using root
warning: group nobody does not exist - using root

Trzeba się upewnić, że dla użytkownika tomcat podstawową grupą jest nobody. Ponadto konieczne jest sprawdzenie, czy dla użytkownika tomcat ustawiono domowy katalog /opt/tomcat/temp, a rolę powłoki logowania przypisano czemuś, co w rzeczywistości nie zadziała (na przykład program /sbin/nologin).

# groupadd nobody
# useradd -s /sbin/nologin -d /opt/tomcat/temp -c 'Tomcat User' \ -g nobody tomcat

Gdy już będzie to zrobione, należy ponownie spróbować zainstalować pakiet tomcat.

# rpm -e tomcat
# rpm -ivh --nodeps tomcat-6.0.14-0.noarch.rpm

Po zakończeniu instalacji wystarczy sprawdzić, czy ścieżka zmiennej środowiskowej JAVA_HOME znajdującej się w pliku /opt/tomcat/conf/tomcat-env.sh wskazuje na żądaną wirtualną maszynę Java w wersji 1.5 lub 1.6. To tyle! Serwer Tomcat powinien być gotowy do uruchomienia.

Za pomocą tych samych pakietów RPM serwer Tomcat można zainstalować, a następnie jego dane przenieść w inne miejsce systemu plików. Oto przykład:

# rpm -ivh --prefix /usr/local tomcat-6.0.14-0.noarch.rpm

Polecenie to zainstaluje Tomcata, zmieniając jego lokalizację tak, że wartością zmiennej środowiskowej CATALINA_HOME stanie się ścieżka /usr/local/tomcat. W ten sposób można też zainstalować pakiety admin i compat.

Podpowiedź

W czasie powstawania książki witryna JPackage.org nie oferowała pakietu RPM serwera Tomcat 6, a jedynie pakiet dla wersji 5.5.

Instalowanie Tomcata z linuksowych pakietów RPM pobranych z witryny JPackage.org

W celu pobrania i zainstalowania pakietów RPM serwera Tomcat oferowanych przez witrynę JPackage.org należy użyć adresu http://JPackage.org/repos.php. Na tej stronie internetowej wyjaśniono, jak skonfigurować metamenedżery pakietów, takie jak yum, apt-rpm, urpmi i up2date. Skorzystanie z takiego menedżera jest jedynym rozsądnym sposobem zainstalowania pakietu RPM serwera Tomcat pobranego z witryny JPackage.org ze względu na dużą liczbę zależności instalacyjnych. Ponieważ szczegóły dotyczące przeprowadzenia konfiguracji repozytorium dla metamenedżera pakietów mogą zmienić się w każdej chwili, nie jesteśmy w stanie zamieścić w książce przykładu demonstrującego przebieg takiej operacji. Więcej informacji można znaleźć na stronie internetowej JPackage.org.

Ostrzeżenie

Pakiet RPM serwera Tomcat 5.5 oferowany przez witrynę JPackage.org tworzy użytkownika i grupę o nazwach tomcat5 i przy ich użyciu uruchamia Tomcata. Domyślną powłoką użytkownika tomcat5 jest /bin/sh. Nie wolno próbować zmienić powłoki, gdyż w przeciwnym razie Tomcat przestanie poprawnie działać.



[1] W celu uzyskania dodatkowych informacji na temat poradzenia sobie z niezgodnością wersji środowiska Java określonej dystrybucji należy zajrzeć do Dodatek A.

[2] Ten pakiet RPM należy traktować jako kod niezbędny do utworzenia binarnego pakietu RPM, lecz niekoniecznie jako kod źródłowy Java samego serwera Tomcat. Pakiet RPM Tomcata dołączony do książki utworzono przy użyciu oficjalnych skompilowanych plików klas. W związku z tym kodu źródłowego Java nie ma w źródłowym pakiecie RPM ani też nie jest potrzebny do utworzenia wieloplatformowego binarnego pakietu RPM.

Instalowanie serwera Tomcat w systemie Solaris

Zanim nowy pakiet serwera Tomcat zainstaluje się w systemie Solaris, prawdopodobnie powinno się go sprawdzić w celu stwierdzenia, czy nie ma już w nim działającego Tomcata. Jeśli tak jest, należy zdecydować, czy powinien zostać usunięty. Domyślnie nie powinien być zainstalowany żaden pakiet Tomcata (dotyczy to przynajmniej systemu Sun Solaris 10).

Podpowiedź

Solaris 9 dysponuje starszą wersją Tomcata. Za pomocą następującego polecenia można sprawdzić, czy serwer Tomcat został zainstalowany:

jnowak$ pkginfo | grep -i tomcat

Jeśli polecenie zwróci jeden lub więcej pakietów, serwer Tomcat jest zainstalowany. Aby uzyskać dodatkowe informacje o pakiecie, należy zastosować narzędzie pkginfo z parametrem -l. Jeśli na przykład wcześniej zainstalowano pakiet serwera Tomcat o nazwie SUNWtomcat, należy wykonać następujące polecenie:

jnowak$ pkginfo -l SUNWtomcat

Jeżeli nawet zainstalowano Tomcata, nie powinno to spowodować problemów. Dla pewności sugerujemy odinstalowanie istniejącego pakietu Tomcata tylko wtedy, gdy jest się przygotowanym na wszelkie szkody wywołane taką operacją. Jeśli ma się pewność, że pakiet jest przyczyną problemów, w celu jego usunięcia jako superużytkownik należy zastosować następujące polecenie:

# pkgrm SUNWtomcat

Aby w systemie Solaris zainstalować pakiet serwera Tomcat, trzeba uzyskać uprawnienia superużytkownika lub innego, który dysponuje możliwością zapisywania plików. Zwykle można to osiągnąć za pomocą polecenia sudo lub su. Oto przykład:

# su -
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
# id
uid=0(root) gid=0(root)

Można następnie przejść do kontynuowania instalacji.

Choć standardowo Solaris jest wyposażony w środowisko Java 1.5.0, powinno się zadbać o zaktualizowanie go do nowszej i bardziej niezawodnej wersji. W Dodatek A można znaleźć szczegóły dotyczące tego, co pobrać i skąd.

W czasie pisania książki jedynym pakietem Tomcata dla systemu Solaris, jaki udało się nam znaleźć, był pakiet serwera Tomcat 5.5 dołączony do zestawu pakietów Blastwave CSW (Solaris Community Software). Jest to wspierany przez społeczność użytkowników zestaw pakietów open source analogiczny do zestawu pakietów dystrybucji Linuksa. Należy zajrzeć na stronę internetową Blastwave CSW (http://www.blastwave.org). Pakiet CSW najlepiej zainstalować przy użyciu narzędzia pkg-get. Choć nie wchodzi w skład systemu Solaris, z łatwością można je zainstalować.

W celu zainstalowania programu pkg-get należy użyć adresu http://www.blastwave.org/pkg-get.php. Do pobrania programu posłużyliśmy się narzędziem wget.

# PATH=/opt/csw/bin:/usr/sfw/bin:/usr/sfw/sbin:$PATH
# export PATH
# wget http://www.blastwave.org/pkg_get.pkg

Jeśli to nie zadziała (na przykład nie zainstalowano narzędzia wget), w celu pobrania pliku pkg_get.pkg na komputer z systemem Solaris wystarczy użyć przeglądarki internetowej.

Oto polecenie instalujące pakiet pkg_get:

# pkgadd -d pkg_get.pkg

Po pojawieniu się monitów należy wcisnąć klawisz Enter lub wpisać y.

W systemowym pliku /etc/default/login należy umieścić ścieżkę.

Najpierw należy zapewnić, że plik będzie mógł być zapisany przez superużytkownika.

# chmod u+w /etc/default/login

W dalszej kolejności należy zmodyfikować plik /etc/default/login przez dodanie następujących wierszy:

PATH=/opt/csw/bin:/usr/sfw/bin:/usr/sfw/sbin:$PATH
export PATH

Dalej należy zapisać plik i usunąć wcześniej nadane uprawnienie.

# chmod u-w /etc/default/login

To samo należy zrobić z plikiem /etc/profile, z tą różnicą, że nie ma potrzeby modyfikowania jego uprawnień. Po otwarciu pliku do edycji na jego końcu należy wstawić identyczne powyższe dwa wiersze, a następnie zapisać zmiany.