Category Archives: Tomcat

Debian jako serwer Javy – Serwery, bazy i routing

Po przygodach z przenoszeniem aplikacji z Jetty na Tomcata serwer ostatecznie stoi. Jest to całkowicie mój VPSik. Pierwotnie działał na nim Gentoo, jednakże nigdy nie bawiłem się z tą dystrybucją w związku z czym trochę szkoda mi było kilku tygodni na rozkminienie o co w tym wszystkim chodzi. Dlatego też decyzja o zainstalowaniu na nim Debiana, dystrybucji dojrzałej, sprawdzonej i szeroko znanej. No i jak wiadomo – support dla niej to cała rzesza linuxowych geeków.

Wstęp

Cel był prosty – stworzyć system, na którym będą działały moje aplikacyjki. Nie wymaga on zatem tuningowania jak wielkie produkcyjne serwisy, ale podstawowe kwestie dotyczące stabilności oraz bezpieczeństwa wypadałloby na nim zrobić. Docelowo na serwerze miały działać następujące usługi:

  • Apache Tomcat
  • bazy danych (MySQL na start, potem doinstaluję Postgresa)
  • języki skryptowe – choćby do wygodnego używania PHPMyAdmin, czy tego typu rozwiązań
  • no i jakiś serwer WWW, by te języki skryptowe mogły gdzieś śmigać

To był plan 0. Otrzymałem Debiana z już zainstalowanym SKD dla Javy, a także ze śmigającym Tomcatem. Instalacja samego kontenera nie jest specjalnie skomplikowana – po prostu ściągamy go poprzez apta i tyle. Jeżeli jednak musimy zaczynać z “gołym” systemem to z pewnością ten link będzie bardzo pomocny. UWAGA!!! Dodam tylko, że występuje tam mały błąd – po instalacji SDK w pliku /etc/profile należy dopisać:

export $JAVA_HOME

Zaś na listingu występuje zapis bez znaczka $. Bez tego nasze aplikacyjki dostarczone z Tomcatem nie ruszą. Wypadałoby też zobaczyć czy na pewno używamy Javy 6. W konsoli:

java -version

Jeśli mamy tam jakieś wersje <1.6 to znaczy, że można też odwiedzić wątek na pewnym forum. Na chwilę obecną zakładam, że wszystko jest dobrze poinstalowane plus używamy najnowszej wersji Javy.

W zależności od potrzeby serwer obsługujemy poleceniami:

/etc/init.d/tomcat-6 start|stop|restart

Konkretna nazwa skryptu może się różnić (w podanym przeze mnie linku jest to /etc/init.d/tomcat). Domyślnie nasz kontener działa na porcie 8080 – jego zmianą zajmiemy się za chwilkę. Uruchamiamy kontener i powinniśmy pod adresem http://localhost:8080 zobaczyć taką oto stronę:

Tomcat jest dostarczany bynajmniej nie jako ‘out-of-the-box’ i trzeba trochę pogrzebać w plikach konfiguracyjnych, aby spełniał w pełni swoją rolę. Domyślnie też jest dostarczany z 2 aplikacjami, które umożliwiają zarządzanie serwerem poprzez interfejs WWW. Pozostawianie ich dostępnych na serwerze produkcyjnym nie jest zbyt dobrym pomysłem (z powodów bezpieczeństwa), ale na etapie stawiania systemu mogą okazać się bardzo przydatne. By jednakże otrzymać do nich dostęp należy edytować plik /var/lib/tomcat6/conf/tomcat-users.xml. U mnie wygląda on tak:

<tomcat-users>
 <role rolename="manager"/>
 <role rolename="admin"/>
 <user username="nasztajnylogin" password="mojetajnehaslo" roles="admin,manager"/>
</tomcat-users>

Oczywiście user i hasło są zmyślone 🙂 W tym pliku XML mamy taki kontenerowy ACL – tworzymy jednocześnie zarówno role jak i użytkowników. Dzięki temu uzyskujemy dostęp do 2 aplikacji zarządzających kontenerem. Są one o tyle istotne na etapie tworzenia serwera, że można szybko i wygodnie poprzez stronę WWW zarządzać serwerkiem. Ja jednakże postanowiłem pobawić się plikami konfiguracyjnymi, zatem usunąłem dostęp do tych aplikacji, a je same wyrzuciłem z serwera.

Baza danych MySQL

Podstawą dla wszystkich aplikacji sieciowych jest baza danych. HowToJava powstała z użyciem MySQLa, podobnie póki co jest i z ProgramBash. Wypadało zatem zainstalować ten RDBMS by mieć na czym operować. W pakietach Debiana znajduje się najnowsza (w miarę) wersja zatem wystarczy użyć apta i jesteśmy w domu. Problemy mogą wystąpić przy próbie połączenia z bazą z zewnątrz – dla przykładu z naszego lokalnego komputera. W moim przypadku Hibernate rzucał wyjątkiem o niemożliwości połączenia się z powodu Connection refused. Innymi słowy – już sam serwer nie chciał mojego requestu. Rozwiązanie jest proste – należy edycji poddać plik /etc/mysql/my.cnf i parametrowi bind-address nie nadawać wartości localhost lub 127.0.0.1, ale IP naszego serwera. Wtedy bez najmniejszych problemów będzie można połączyć się z lokalnej maszyny. Nalezy także pamiętać o utworzeniu użytkownika z odpowiednimi prawami (łączącego się z określonego hosta). Na koniec zabaw ze zmianą uprawnień wydajemy polecenie:

flush privilages;

Bez tego można kląć na potęgę dlaczego nasze zmiany w uprawnieniach nie są widoczne.

Routing lub też proxy jak kto woli

Domyślnie Tomcat (choć dotyczy to w sumie wszystkich serwerów/kontenerów Javy z jakimi miałem okazję pracować) działa na porcie 8080 lub okolicach. Rzecz jasna w przypadku podpinania domeny pod nasz serwer takie rozwiązanie nie za bardzo wchodzi w grę – wszak nie można ustawić w routingu domen docelowego portu. Przyjęło się, że w użyciu mamy port 80 – tam przeglądarki standardowo wysyłają swoje żądania. Cóż zatem zrobić, aby wykupiona domena wskazywała na nasze pliki z aplikacjami Javy (u mnie to WARy) i wyglądało to transparentnie? Mamy kilka rozwiązań:

  • ustawienie portu w konfiguracji Tomcata na numer 80. Proste, ale absolutnie niezalecane ze względów bezpieczeństwa!!!
  • forwardować ruch poprzez odpowiednią konfigurację firewalla. Iptables to dobre narzędzie do tego.
  • postawić nasz serwer/kontener Javowy za zwykłym serwerem WWW, który będzie działał jako proxy.

Powyższe rozwiązania zostały dokładnie omówione w tym miejscu, a i z pomocą Gogla, można dowiedzieć się wszystkiego. Ja również pierwotnie myślałem o postawieniu Apache i zastosowaniu connectorów, jednakże moi mili admini wyperswadowali mi takowy pomysł i stanęło na podobnym rozwiązaniu, ale w oparciu o szybki serwer WWW – nginx. Oficjalna stronka znajduje się pod adresem http://nginx.org/. Sam serwer ma swoje plusy i minusy, by się z nimi zapoznać zapraszam do artykułu w Wikipedii. Sam serwer posłuży też do obsługi PHP – konkretniej do narzędzi zarządzających bazą danych (wygodny jestem), a także być może w przyszłości hostowania tego bloga.

Instalacja nginxa jest banalnie prosta:

sudo apt-get install nginx

I nasz serwerek jest już zainstalowany. Całkiem przyzwoity materiał o tym serwerze można znaleźć u Riklaumina, ja ograniczę się na razie do pierwszego jego uruchomienia. Tuningiem i bliższym poznaniem zajmę się w kolejnych artykułach. Przede wszystkim należy przejśc do katalogu /etc/nginx/conf.d. Cokolwiek znajdzie się w tym katalogu zostanie domyślnie potraktowane jako plik konfiguracyjny. Należy utworzyć nasz podstawowy plik konfiguracyjny:

cd /etc/nginx/conf.d
touch default.conf

Edytujemy stworzony plik i wrzucamy w niego na przykład taki oto kod:

 server {
        listen       80;
        server_name  WPISUJEMY_NASZE_IP DOMENA1 DOMENA2 DOMENA3;

        # Main location
        location / {
            proxy_pass         http://127.0.0.1:8080/;
            proxy_redirect     off;

            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

            client_max_body_size       52m;
            client_body_buffer_size    128k;

            proxy_connect_timeout      3600;
            proxy_send_timeout         3600;
            proxy_read_timeout         90;

            proxy_buffer_size          4k;
            proxy_buffers              4 32k;
            proxy_busy_buffers_size    64k;
            proxy_temp_file_write_size 64k;
            proxy_cache_valid 5m;
        }
    }

To baaaaardzo podstawowa konfiguracja. Ale na pewno osiągnęliśmy jedno – wszystkie requesty domyślnie lecące na port 80 zostaną przekierowane na port 8080, gdzie będzie na nie już oczekiwał nasz Tomcat. Można odpalić nginxa poleceniem:

/etc/init.d/ngninx start

Być może trzeba będzie po raz pierwszy zrobić to z poziomu konta administratora. Jak widać sam serwer zainstalował skrypt, ktory uruchamia go przy starcie systemu (w katalogu /etc/init.d/).

Tomcata musimy odpowiednio poinformować o istnieniu czegoś takiego jak subdomeny. I tutaj właśnie pobawimy się plikami konfiguracyjnymi (choć będzie to dość szybka zabawa). Docelowo mój serwerek zainstalował się w katalogu /var/lib/tomcat6/. W tymże katalogu znajduje się również podstawowy katalog dla naszych aplikacji – webapps. Dla naszych aplikacji, które zamierzamy wdrożyć należy przygotować pliki dystrybucyjne – ja pozostaję od samego początku wierny plikom WAR. Teraz musimy wyedytować plik konfiguracyjny Tomcata. W naszym ulubioym edytorku bierzemy na tapetę plik /var/lib/tomcat6/conf/server.xml.

 <Host name="SUBDOMENA_Z_DOMENA" appBase="webapps/NAZWA_SUBDOMENY" unpackWARs="true" autodeploy="true"></Host>

Restart Tomcata i należy udać się pod powyżej wpisany adres. Oczywiście serwer nie znalazł ani katalogu, ani pliku o wskazanej nazwie (jeszcze nic nie wysłaliśmy na serwer), zatem przekierował nas na główną stronę w domenie. Jednakże póki co wszystko działa poprawnie – nie dostaliśmy od serwerów po drodze błędu 404. Do testów maszyny najlepiej na szybko stworzyć maksymalnie prosty projekt w Javie (ja użyłem przykładowego projektu JSF). Generujemy dla niego plik WAR i łączymy się z serwerem dowolnym klientem FTP/SCP/SSH (w zależności co lubimy i co mamy/odpaliilśmy na serwerze). Przesyłamy do katalogu webapps nasz plik WAR i tworzymy dla niego katalog. Dla ułatwienia stworzyłem subdomenę example.chlebik.pl jak i odpowiedni katalog. Do niego wrzuciłem plik WAR. Uwaga!!! Można naciąć się na uprawnieniach do katalogów lub plików. Podążając tropem aktywności mojego Tomcata wszystkie pliki i katalogi przypisuję do użytkownika tomcat6 oraz grupy o tej samej nazwie. Przynajmniej nie dostaję ukochanego komunikatu – Permission denied.

Powyżej w pliku server.xml ustawiliśmy, że ta konkretna aplikacja ma być deployowana na starcie serwera, a także ma mieć rozpakowany plik WAR (dla zwiększenia szybkości działania). Ponownie odwiedzamy adres naszej subdomeny – i nic. Dalej jesteśmy przekierowywani na główną stronę domeny. Cóż się stało? Ano taka dziwna cecha Tomcata – wystarczy nasz plik WAR znajdujący się (u mnie) w katalogu webapps/example/, przemianować na webapps/example/ROOT.war. Restart serwera i co? Hip-Hop, hurrra. Dostajemy miły komunikat od JSF i Facelets, że nasza aplikacja działa. Można z ciekawości zajrzeć do tego katalogu – został tam rozpakowany w podkatalog o takiej samej nazwie jak plik WAR cały kod naszej aplikacji. Dlaczego w ten sposób? Uważam, że w katalogu z aplikacjami powinny być inne katalogi, a nie stado plików WAR lub inszych, które zaciemniają obraz. Każda aplikacja ma swój katalog i niech w nim dzieje się co chce.

PHP i Fast-CGI

Na koniec został mi do zainstalowania PHP. O ile w przypadku pierwotnie planowanego Apache rzecz jest banalna, o tyle nginx wymaga trochę zabawy. Należy bowiem doinstalować specjalny moduł do obsługi języków skryptowych poprzez Fast-CGI. Tutaj korzysta się z dobroci serwera lighttpd, ale o tym można już poczytać sobie w artykule. Dodam tylko by odpowiednio skroić nasz plik default.conf z nginxa – można połączyć konfig FCGI z PHP z istniejącą konfiguracją, ale można też zastosować podejście opisane w powyższym tutorialu. Co więcej – nginx jest tak fajnym narzędziem, że przy restarcie waliduje swoje pliki konfiguracyjne – jeśli coś jest nie tak wówczas od razu zostaniemy o tym poinformowani bez konieczności przeglądania logów serwera.

Co dalej?

Mam nadzieję, iż trochę ułatwiłem początkującym adminom życie (jakbym ja miał 10 lat doświadczenia :). W ramach możliwości postaram się kontynuować tak mile rozpoczęty cykl wpisów o administracji serwerem dla programistów. Jeśli znalazłeś jakikolwiek błąd w powyższym materiale lub masz jakieś sugestie – rzecz jasna zapraszam do kontaktu lub komentowania. Gdyby ktoś był zainteresowany VPSem lub hostingiem tam gdzie ja to należy pisać na ten adres email. Przy okazji możecie wspomnieć, że to dzięki mnie wiecie o usłudze 🙂

Tak na koniec

Na sam koniec dobra rada dla wszystkich programisto-administratorów 🙂 Jakiekolwiek operacje na sewerze (dedyku, VPSie czy w ogóle czymkolwiek) lepiej wpierw przetestować na VirtualBoxie. Produkt firmy SUN świetnie się do tego nadaje. Nie będę opisywał tutaj procesu instalacji i tak dalej, dam tylko kilka szybkich rad dla uruchamiania wirtualizacji systemu w Windows XP:

1. Używana przestrzeń dyskowa na system linuxowy powinna być wrzucona na partycję z systemem plików innym niż FAT32!! Inaczej dostaniemy błędy podczas instalacji, albo użytkowania, gdyż ten format nie obsługuje istnienia plików powyżej 2 GB.
2. W świetle powyższego – skonfigurować wirtualną maszynę by miała rozszerzalne miejsce na partycji. Często coś tam się doinstaluje, odinstaluje lub chce pobawić i nagle BUM – nie ma miejsca.
3. Jeżeli naszego linuxa instalujemy wraz ze środowiskiem graficznym należy ściągnąć VBoxLinuxAdditions. Jest to obraz płyty, który po instalacji naszego systemu należy podpiąć i następnie uruchomić z poziomu linuxa. U mnie wymagało to doinstalowania kilku rzeczy (nagłówków jądra linuxa i czegoś jeszcze). Kiedy to wszystko już zrobimy uruchamiamy po prostu skrypt .sh dla linuxa i stosownej architektury. Dzięki temu będziemy mogli rozszerzać ekran z wirtualizowanym systemem, grafika przestanie się ciąć i w ogóle będzie lepiej.
4. RZECZ BARDZO ISTOTNA!!! Dość często ludziom zdaża się, że uruchomienie VBoxa nawet z czystą konsolą (bez fajerwerków KDE czy GNOME) powoduje zżarcie przez VBoxa jakiś 50-90% procesora. Strasznie to wkurzające – dzieje się tak niezależnie od przydzielonej ilości RAMu. Rozwązaniem jest wyłączenie antywirusa!! U mnie działa darmowy AVG – jego wyłączenie automatycznie zredukowało zasobożerność VBoxa. Domyślam się, że chodzi o monitorowanie wirtualnego połączenia internetowego. Z tego co wyczytałem w sieci również niektóre fiewalle zachowują się w podobny sposób.

Advertisements

VPS gotowy

W tym jakże pięknym choć mroźnym dniu nadejszła wielkopomna chwila – mój VPS oficjalnie zostaje zaprezentowany światu.

Punktem wejścia jest domena chlebik.pl, gdzie znajduje się mini-portfolio z linkami, które prowadzą do aplikacji i bloga. Od dziś aplikacje stworzone przeze mnie i działające online będą podpinane pod kolejne subdomeny. Na razie zatem mamy http://programbash.chlebik.pl oraz http://howtojava.chlebik.pl.

Na VPSie działa Tomcat, który okazał się o wiele bardziej przyjazny dla moich aplikacji niż Jetty. Jak serwer proxy przed nim został postawiony superlekki Ngix, zaś system to sprawdzony od lat Debian. Zaniedługo pojawi się pierwszy wpis dotyczący sposobu skonfigurowania takiego serwera, a w przyszłości wpisy na temat optymalizacji oraz zabezpieczania serwera. Na razie to tyle – zapraszam do odwiedzin.

Chlebik leży i kwiczy

Kwiczy i leży. Trwają prace nad przeniesieniem aplikacji na VPS  z Tomcatem na pokładzie. Dlatego niestety wszystkie aplikacje, które stworzyłem edukacyjnie wraz z wpisami na blogu są nieaktywne. Stan ten utrzyma się jeszcze przez kilka dni niestety. Ale pewnie będę mógł napisać kilka ciekawych wpisów o konfiguracji Debiana do pracy jako serwer dla Javy.

Swinguj z nami czyli piszemy aplikację cz.2

Po kilku miesiącach od pierwszego wydania przyszła kolej na krok dalej – oto druga wersja klienta do gry w Arkadię, opartego na Swingu i mojej niedostatecznej znajomości Javy 🙂

Przyznaję, że wydanie to mogłoby pojawić się wcześniej. Jednakże wpierw mały romans z JEE, a potem wypadki losowe odwlekły ten fakt w czasie. Przez kilkanaście ostatnich dni przysiadłem fałdów i oto jest – druga wersja ChlebikClient. Wiele jeszcze jej brakuje do optymalnego funkcjonowania jako wymarzony klient, jednakże widać już pewne zarysy jak mogłaby wyglądać taka aplikacja, kiedy bierze się za nią newbies. Jednakże postanowiłem, że wydanie drugie będzie również i ostatnim – gdyż kolejne wydania byłyby po prostu dokładaniem bardzo podobnych do obecnych cegiełek. Czyli kolejny JInternalFrame, kolejny plik XMLa i tak dalej – ani to wiele już nie rozwija, a i sensowności dalszej w tym nie ma zbyt wiele.

Popracowałem z NetBeansem używając jego pomocy do tworzenia GUI, mam mniej więcej pojęcie o wątkach aplikacji pisanej w Swingu (choć i tak niewiele jak znam życie), operowanie podstawowe na plikach XML, poszczególne komponenty też obejrzałem sobie z kilku stron. Na dzień dzisiejszy dalsze prace zostają wstrzymane i odłożone na czasy obfitujące w wolny czas (może kiedyś nadejdą). Póki co zapraszam na podstronę projektu, gdzie można przeczytać listę zmian oraz ściągnąć najnowszą wersję.

Co zaś do przyszłości – zmierzam w kierunku JEE. Dla nauki rozpoczynam pisanie aplikacji internetowej. Wstępnie technologie użyte to JSP, Hibernate/JDBC, wszystko zapakowane w Tomcata. Być może tym razem spróbuję użyć do pracy Eclipse’a wraz z jego rozszerzeniem WTP.

JSF i dlaczego jestem zdumiony

Jak wspomniałem w jednym z poprzednich wpisów nabyłem trochę ciekawych książek o wiadomym temacie. No i po tym jak ‘prześlizgnąłem się’ po Head-First JSP i Servlety zabrałem się od razu za Core JSF. I ZONK! Po raz kolejny podejście wzięte z PHP sprawiło, że uderzyłem o ścianę. Ale tym razem cholera miało być inaczej.

Tok mego rozumowania był prosty – mamy JSP i serwlety. Służy to do pisania aplikacji webowych dla platformy JEE (nie całych, ale na pewno widoku i kontrolera). Znaczy się może służyć, bo wiadomym jest, że dzisiaj raczej w czystych językach nikt nie pisze – używa się różnych bibliotek i komponentów, których połączenie często okazuje się na tyle fajne, że powstaje framework. I takie coś mamy w PHP – język językiem, no ale w okolicy wersji 5.1 kiedy to OOP przestało być czymś na papierze, a stało się rzeczywistością pojawiły się pierwsze frameworki. Kiedy rozpoczynałem pracę jako koder PHP dostałem się w szpony Zend Frameworka i wciąż w nich tkwię. Po drodze bawiłem się trochę Symphony, a także RORem (choć to inny język). Dla mnie zatem framework to zestaw przynajmniej gotowych komponentów, które rutynowe czynności w budowie aplikacji sprowadzają do inicjalizacji kilku obiektów i wywołania ich metod. To co potrafi momentami Symphony czy ROR to już w ogóle kosmos i nic dziwnego, że ludzie tego używają.

Wracając do Javy – myślałem, że JSP to takie PHP, no a JSF to framework, czyli liznę tego pierwszego na razie byle się tylko orientować, przepatrzę książkę o JSFie i wezmę się za pisanie projektu łączącego tę wiedzę w jednym. Może to wina książki, albo i samego narzędzia. Jednakże załamało mnie to, iż po lekturze 100 stron to wiem na pewno, że wszystko o czym czytam zostanie omówione w następnych rozdziałach. No nic, przepatruję z ciekawości spis treści. Przerobiłem na chwilę obecną wstęp, coś o beansach, rozdzialik o nawigacji (XML rządzi) i zacząłem znaczniki standardowe. Zostaje mi rozdział o znacznikach niestandardowych, weryfikacji danych, obsłudze zdarzeń i… w sumie nic. Bo następne rozdziały to niestandardowe elementy, potem JDBC/LDAP, AJAX no i omówienie bardzo pokrótkie inych frameworków!!! Na koniec mam rozdział zatytułowany ‘Jak to zrobić?’. Mam pomysł by na tym pytaniu oprzeć ćwiczeniowy projekt pisany w JSP (aplikacji internetowej) zatem przerzuciłem te 400 stron i wziąłem się za szybkie przeglądanie rozdziału. ZONK!

Rozbiło mnie już pytanie trzecie (sic!) na łącznie około 35. Jak zaimplementować obsługę wysyłania plików na serwer?. O nareszcie coś z bliskich mi klimatów. Dla niezorientowanych w temacie PHP wyjaśniam – w tym języku jest to kwestia sprawdzenia czy przesłano element “file” z formularza, po czym sprawdza się czy plik doszedł i zapisuje się go w docelowym katalogu. W wersji spartańskiej robi się to może 5 linijkami kodu (wliczając po nawiasach klamrowych na linię). W Zend Frameworku mam do tego jego element w postaci Zend_File, a w nim cuda niewidy – walidatory, filtry, plus adaptery dla wysyłania plików. Można to łatwo zobaczyć – kilka linii kodu i działamy.

A co mamy w JSF? Chwilka, już liczę… Serwlet filtrujący (109 linii kodu) plus klasa renderująca (89 linii) plus klasa dla znacznika ( 28 linii ) plus sam plik JSP ( 18 linii ), ale to można pominąć. Szybkie dodawanie i okazuje się, że by wysłać plik na serwer i wiedzieć, że dotarł cały i bezpieczny muszę sklepać ponad 200 linii kodu!!! Cholera no to jest framework czy jakiś #$@#@%^^%? Jak można nazywać taką technologię frameworkiem, skoro zamiast usprawniać tworzenie aplikacji niewiele ona w sobie zawiera? No niby co poza jasno określonym MVC (ale przecież JSP też to ma, a tu jeszcze od cholery XMLa na ścieżki nawigacji), pomocą z renderowaniem widoku (View) czy w końcu znacznikami JSF technologia ta może zaoferować?

Ufff, przepraszam, uniosłem się, to był przedostatni raz. Naprawdę zaczynam rozumieć, dlaczego w ogłoszeniach o pracę dla javowców wymienia się po 4 elementy z każdej dziedziny (Struts, Spring, JSF, Ant, Maven, Hiberante, TopLink, iBATIS, JBoss, WebSphere, Tomcat). Nie wiem, ja generalnie młody jestem, zaczynam bawić się w te klocki, ale błagam, niech ktoś mi powie: “potem będzie lepiej”. Framework będzie frameworkiem z zapleczem, a nie tylko ulepszonymi grabiami czy łopatą. Proszę niech ktoś powie: “młody jesteś, ucz się dalej”. Jak już poznasz to zrozumiesz.

Proszę 🙂

Java Server Pages i servletowe podwórko

Wspomniałem już przy okazji poprzedniego wpisu o serwletach oraz o technologii Java Server Pages. W dużym skrócie – serwlety to po prostu aplikacje Javy wykonywane po stronie serwera, zaś JSP to technologia umożliwiająca dynamiczne generowanie dokumentów (X)HTML poprzez osadzenie w kodzie HTMLa wstawek z języka Java (za Wikipedią). Dodatkowo rzecz z automatu jest realizowana we wzorcu MVC (Model-View-Controller), co można ostatecznie podsumować stwierdzeniem, że mamy bardzo przyjemne narzędzie do tworzenia aplikacji internetowych.

Dlaczego o tym piszę? Albowiem jako programista PHP pracujący nad projektami o bardzo pojemnej nazwie ‘webdevelopment’ automatycznie kieruję się w stronę znanych mi rozwiązań, a za takowe JSP (i potem Java Server Faces – to framework) można uznać. Jednoczesne poznawanie Javy (za pomocą Bruce’a Eckela i jego ‘Thinking in Java’) oraz JSP (książka ‘Head First JSP’) póki co okazało się dość obiecującym rozwiązaniem, gdyż zamiast klepać standardowe do bólu System.out.println i zachwycać się rozbudowaną konwersacją z konsolą, można tworzyć kod wypełniając znany sobie szkielet aplikacji (np. tworząc system blogowy).

Do rozpoczęcia zabawy z JSP potrzebujemy jednej rzeczy – kontenera na serwlety. Rolę tę pełni świetnie Apache, kiedy doinstaluje się do niego odpowiedni moduł, albo też kiedy zainstaluje się Apache Tomcat jako samodzielny serwer (www + jsp w jednym). Zasadniczo wyszedłem od tej koncepcji (czy wspominałem już, że jestem leniwy jeśli chodzi o babranie się z administracją?), a następnie spróbowałem jakoś to wrzucić (pluginem oczywiście) pod Eclipse’a. Po strawieniu 3h nad konfigiem oraz próbą zmuszenia tej aplikacji by w końcu zobaczyła mój plugin do Tomcata dałem za wygraną i postanowiłem ściągnąć NetBeans. Downloaded, zainstaluj, uruchom, ściągnij update i viola!!! Nagle okazało się, że wystarczy stworzyć nowy projekt i nacisnąć ‘Build all’ – wszystko pięknie śmiga. Jako, że była gdzieś 3 nad ranem porzuciłem zabawę, ale wróciłem do niej zaraz następnego dnia.

NetBeans ma to do siebie, że można go ściągnąć w kilku wersjach. Bardzo ważne jest to, że możemy również wybrać wersję niejako ‘out of the box’, gdyż razem z IDE dostarczany jest też Tomcat oraz GlassFish (to serwer aplikacji J2EE firmy Sun). Po zainstalowaniu otrzymujemy (pod Windowsem oczywiście) w pełni skonfigurowane narzędzie. Tutaj właśnie uwaga – opiszę co i jak by skonfigurować pierwszy projekt i uruchomić go. W książce ‘Head First JSP’ przedstawiono podział na 2 środowiska – developerskie oraz aplikacyjne (czyli produkcyjne). Jest to rozwiązanie poniekąd słuszne, jednakże na czas nauki, kiedy człowiek musi przypominać sobie czasem składnię podstawowych funkcji, jakoś nie widzę ku temu sensu.

W NetBeans zatem skonfigurujemy projekt tak, aby dało się w obrębie jednego katalogu jednocześnie posiadać kod źródłowy, jak i widzieć go (po kompilacji oczywiście) z poziomu przeglądarki. Oto co trzeba zrobić:

1. Okienko z projektami -> prawy przycisk myszy i oczywiście New Project
2. Pokazuje się lista do wyboru, nas interesuje Web, a potem Web Application
3. Nadajemy projektowi nazwę, NetBeans automatycznie poda domyślną ścieżkę do niego (czyli katalog webapps w katalogu gdzie zainstalowano Tomcata).
4. Pojawią się informacje o używanej wersji serwera i takich tam – wybieramy oczywiście to, co zainstalowane (najprawdopodobniej Tomcat 6.0, Java EE 5).
5. W następnym kroku mamy możliwość wyboru używanego frameworka. Jako, że nic takiego na razie nie ma miejsca, to klikamy Finish i mamy gotowy szkielet projektu.

By przetestować działanie całości należy prawym przyciskiem myszy kliknąć na nasz projekt (w okienku projektów) i wybrać Build. NetBeans nam pokompiluje co trzeba i następnie znowu pod prawym przyciskiem wybieramy Run i po paru sekundach mielenia otwiera się nam przeglądarka i pojawia się śliczne ‘Hello wordl!’ (adres to http://localhost:8084/TWOJANAZWAAPLIKACJI/).

Teraz kiedy już mamy działający projekt trzeba objaśnić trochę strukturę katalogów. Różni się ona od przyjętej w ‘Head First’, zatem dla jasności napiszę co i gdzie. Struktura katalogów w folderze naszej aplikacji wygląda tak:

1. Katalog nbproject to internalsy NetBeans i nie należy tego na razie dotykać.
2. Podobnie rzecz ma się ze znajdującym się w katalogu aplikacji plikiem build.xml oraz katalogiem dist – to informacje na temat sposobu budowania projektu, a w katalogu z kolei umieszcza się ostatecznie przygotowaną paczkę z kodem (w formie pliku *.war).
3. Katalog test służy zgodnie z nazwą do testów (testów jednostkowych opartych na JUnit)
4. W katalogu build zgodnie z nazwą budowany jest cała aplikacja
5. W katalog src znajduje się nasz kod źródłowy
6. I na sam koniec w folderze web znajdują się nasze pliki *.jsp i *.html (wraz z plikiem web.xml).

Oczywiście normalnie nikt nie będzie grzebał bezpośrednio w plikach w tym folderze – od tego jest IDE. Jednakże dobrze wiedzieć co i z czym, zwłaszcza dla początkujących informacja ta może być dość istotna. Nasz projekt póki co nie zawiera kodu Javy, ale jest w pełni gotowy na jego przyjęcie. Na razie rzut oka na okienko IDE:

Aplikacja na razie jest dla nas interesująca w dwóch miejscach. Pierwszym z nich jest katalog Source Packages. Tutaj należy dodawać kolejne pakiety, a w nich klasy (np. com.wordpress.chlebik.TestowaKlasa.java). Umieszczone tutaj zostaną w procesie budowania projektu skompilowane i przerobione na postać strawną dla serwera. Drugim ważnym katalogiem jest katalog web, gdzie znajduje się cały HTMLowy lub JSPowy kod. Dla przykładu – znajdź w tymże folderze plik index.jsp i zmień jego nazwę na np. index2.jsp. Teraz w przeglądarkę wrzuć adres http://localhost:8084/WebApplication1/. I co? Ano nic, błąd. Ale z kolei wpisanie http://localhost:8084/WebApplication1/index2.jsp już jak najbardziej działa. Na prostym przykładzie widać, co gdzie i z czym jeśli chodzi o HTML i JSP. W katalogu tym można również odnaleźć podkatalog WEB-INF gdzie znajduje się plik web.xml, który służy do (powiedzmy uogólniając) kierowania routingiem w naszej aplikacji. Jednakże to uczący się JSP już raczej wiedzą i nie potrzeba tego tematu rozwijać.

Mam nadzieję, że to krótkie i pewnie trochę chaotyczne wypociny jednakże komuś pomogą, a i może skłonią do sięgnięcia po NetBeans.