Spis treści Wstęp do Javy Web...2 Podstawowe pojęcia...2 Przygotowanie środowiska...3 Tworzenie aplikacji webowej w NetBeans...4 Serwlet - klasa obsługująca żądania HTTP...8 Klasa HttpServlet najważniejsza klasa Javy Web...8 Plik web.xml mapowanie serwletów...12 Mapowanie serwletu za pomocą adnotacji...13 Zaczynamy development metody doget(), dopost(), parametry żądania...14 Pliki JSP, atrybuty żądania...17 Łatwa generacja kodu HTML...17 Mechanizm dispatcher a, atrybuty żądania - łączymy controller z widokiem...18 Cykl życia serwletu i ich uruchamianie wraz ze startem serwera...21 Cykl życia serwletu...21 Uruchamianie serwletu wraz ze startem serwera...23 Tagi JSTL...25 Tag c:if najprostsza instrukcja warunkowa...30 c:choose czyli bardziej złożone warunki...32 Biblioteka fmt formatujmy nasze dane...33 fmt:formatdate formatowanie dat...33 W Javie miesiące oznaczamy jako duże MM!...35 Tag fmt:formatnumer formatowanie liczb...35 Skryptlety - kod Javy w plikach JSP...37 Obsługa formularzy w Javie Web...39 Kontener serwletów Tomcat 7...47 Instalacja Tomcat 7...47 Pierwsze uruchomienie kontenera Tomcat...50 Uruchomienie Tomcat7 na systemie Linux Mint...52 Instalowanie aplikacji webowej na Tomcat 7...54 Instalacja Tomcat 7...54 Pierwsze uruchomienie kontenera Tomcat...57 Uruchomienie Tomcat7 na systemie Linux Mint...58 Korzystanie z Tomcat7 w NetBeans i zmiana portu nasłuchu Tomcat7...60 Uruchomienie Tomcat'a na porcie 80...63 1/64
Wstęp do Javy Web Podstawowe pojęcia Zajmiemy się teraz tworzeniem aplikacji webowych w Javie. Wszystko opiera się na istnieniu serwera, który otworzy port 80 (usługa HTTP), i przekaże żądanie do jakiejś klasy zdolnej do przyjęcia tego rodzaju obiektu i do wygenerowania odpowiedzi. Taką w klasą w Javie jesthttpservlet. Aplikacja webowa musi zostać zainstalowana na jakimś serwerze (lub kontenerze serwletów) i dopiero tam można ją uruchomić. O ile kompilacja aplikacji desktopowych tworzy paczkę z rozszerzeniem JAR, o tyle kompilacja aplikacji webowej tworzy paczkę z rozszerzeniem WAR. Java Web to część Javy Enterprise Edition. Założyłem, że czytelnik posiada podstawową wiedzę z zakresu HTML i CSS, a także podstawę protokołu HTTP (np. znajomość różnicy między żądaniami typu GET i POST) 2/64
Przygotowanie środowiska Jak wynika z powyższego podrozdziału na pewno będziemy potrzebować jakiegoś serwera. W rzeczywistości środowisko musi posiadać dużo więcej modułów. Skonfigurowanie środowiska NetBeans na szczęście sprowadza się tylko do ściągnięcia pliku instalacyjnego z oficjalnej strony IDE - https://netbeans.org/downloads/index.html: Jeśli posiadasz już zainstalowane NetBeans IDE do Javy SE, nie musisz go odinstalowywać. NetBeans wykryje obecną instalację i doinstaluje odpowiednie moduły. Sam proces instalacji jest całkowicie standardowy. Ważne jest aby zainstalować razem z NetBeans IDE serwer GlassFish. Dzięki temu nie będziemy musieli tracić czasu na 3/64
instalowanie zewnętrznego serwera, jego skonfigurowanie i integrowanie ze środowiskiem. Tworzenie aplikacji webowej w NetBeans Po doinstalowaniu modułów do środowiska, wybieram tworzenie nowego projektu. W menu pojawią się nowe opcje: 4/64
Pierwszy ekran to wybór nazwy naszego projektu. Drugi to wybór serwera na który NetBeans będzie deploy ował naszą aplikację. Context path to ścieżka pod jaką aplikacja będzie widoczna w sieci. Te opcje pozostawimy domyślne: Ostatni ekran to wybór framework ów, które zostaną automatycznie dołączone i skonfigurowane w naszym projekcie. Na tym ekranie nie wybieramy żadnego framework a, będziemy pisać w czystej Javie. W końcu po kliknięciu finish w panelu projektów pojawi się nowy wpis: 5/64
Tak wygląda podstawowa struktura projektu. W katalogu Web Pages znajdują się wszystkie pliki potrzebne do poprawnego działania dokumentów HTML odpowiedzialnych za widoki. Znajduje się w nim katalog WEB-INF w którym umieszczamy pliki konfiguracyjne aplikacji, użytkownik nigdy nie ma dostępu do katalogu WEB-INF. Zawsze znajdziemy tam plik web.xml czyli tzw. plik deskryptora jest to w zasadzie najważniejszy plik w całej aplikacji. Omówimy go bardzo dokładnie. Katalog Source Packages to dobrze znana nam część aplikacji w której znajdują się pliki z kodem źródłowym. Jeśli chodzi o sekcję Libraries zwróć uwagę, że w pustym projekcie poza bibliotekami z JDK znajdują się też biblioteki z serwera aplikacyjnego, dzięki którym uruchomimy specjalne klasy charakterystyczne dla aplikacji webowych. Aplikację uruchamiamy dokładnie tak samo jak w przypadku aplikacji desktopowych przyciskiem Run Project z toolbar a w NetBeans. Proces jest jednak bardziej złożony od programów Java SE, trakcie uruchamiania aplikacji webowych projekt jest kompilowany, budowana jest paczka (plik WAR), uruchamiany jest serwer i w końcu paczka zostaje zainstalowana na serwerze. 6/64
W przeglądarce zostanie uruchomiona nowa karta z naszą aplikacją oczywiście wyświetli się zawartość pliku index.html. Właśnie stworzyliśmy najprostszą, działającą aplikację działającą w interfejsie webowym. Gratulacje! 7/64
Serwlet - klasa obsługująca żądania HTTP Klasa HttpServlet najważniejsza klasa Javy Web Wrócimy na moment do modelu warstwowego aplikacji pamiętasz warstwę Controller i View? W przypadku aplikacji webowych rozdzielamy te warstwy. Controller ami będą klasy dziedziczące po HttpServlet, a widokami pliki JSP a których będziemy jeszcze mówić. Stworzę zatem teraz odpowiedni pakiet w którym będę przechowywał serwlety, a w nim nowy serwlet: 8/64
Serwlet jest zwykłą klasą Javy, ale wymaga dodatkowej konfiguracji, dlatego po podaniu nazwy klasy klikamy na Next i wychodzimy na poniższe okienko: To jest właśnie część konfiguracyjna serwletu. Servlet Name to nazwa pod jaką serwlet będzie widoczny w obrębie aplikacji nie musi to być nazwa klasy (w każdym razie musi być to nazwa unikalna). URL Pattern(s) to adres lub adresy URL po wejściu w które uruchomiony zostanie serwlet. Checkbox oznacza dodanie wpisu o serwlecie do 9/64
pliku web.xml, nie jest to absolutnie konieczne ale na razie nie będziemy wnikać w szczegóły XML a, zajmiemy się nim później. Po kliknięciu Finish zostanie stworzony nowy serwlet, a do pliku konfiguracyjnego środowisko doda odpowiedni wpis. Klasa MainController: Omówimy teraz samo pojęcie serwletu i jak jest zbudowany. Serwletem jest sama klasahttpservlet i wszystkie klasy, które po niej dziedziczą. Jest to jedyna klasa zdolna do obsługiwania żądań HTTP i generowania odpowiedzi. W HttpServlet zdefiniowano 10/64
metodydoget() i dopost(), które są uruchamiane dla odpowiednich żądań. Metoda processrequest()to kawałek kodu, który dokleja sam NetBeans i jest ona całkowicie niepotrzebna. Jeśli nic nie zmienimy w kodzie serwletu zostanie ona uruchomiona niezależnie od typu żądania. Sprawdźmy czy serwlet wywołuje się poprawnie: Wywołanie adresu, który podaliśmy jako URL Pattern powoduje uruchomienie metodyprocessrequest(). 11/64
Plik web.xml mapowanie serwletów Żeby serwer wiedział, który serwlet ma uruchomić w reakcji na dany adres URL potrzebny jest plik konfiguracyjny. Otworzymy teraz plik web.xml i przeanalizujemy jego strukturę: W szczególności interesować nas będą tagi od linijki 7 do linijki 15. Najpierw trzeba w obrębie aplikacji zdefiniować serwlet i powiązać go z odpowiednią klasą. Jest to odpowiedzialność tagów: 12/64
Następnie musimy powiązać konkretny serwlet z adresem (lub adresami) URL. W tym celu określamy tę konfigurację poniższymi tagami (URL Pattern zawsze rozpoczynamy od slash a): Mapowanie serwletu za pomocą adnotacji Jeśli budujemy dość dużą aplikację plik web.xml bardzo szybko puchnie do tysięcy linii kodu XML. Konfiguracja XML to podstawowy sposób mapowania serwletów istnieje jednak nowszy za pomocą adnotacji @WebServlet. Podstawowa składnia takiej adnotacji wygląda tak jak na poniższym screen ie. 13/64
WAŻNE! Adnotacja @WebServlet została wprowadzona wraz z Servlet 3.0 API. Chcąc jej używać, musimy upewnić się najpierw czy serwer, na którym zainstalujemy aplikację obsługuje API 3.0. Zaczynamy development metody doget(), dopost(), parametry żądania Wrócimy do serwletu, który tworzyliśmy przed chwilą Przyjrzymy się też najważniejszym metodom każdego serwletu czyli doget() i dopost(). Po usunięciu metody processrequest(), odwołań do niej oraz komentarzy dokumentujących wygodzę na coś takiego: 14/64
Jak widzisz obie metody przyjmują dwa argumenty reprezentujące obiekt żądania i obiekt odpowiedzi HttpServletRequest i HttpServleResponse. Zajmiemy się najpierw najprostszymi operacjami, czyli wypisywaniem czegoś na ekran. W aplikacjach webowychsystem.out.println() działa troszkę inaczej: Aplikacje webowe mają niejako dwa ekrany: pierwszym są logi serwera, a drugim przeglądarka. Sprawdźmy co się stanie: 15/64
OK. Wszystko bardzo ładnie, ale chcielibyśmy, żeby nasz serwlet był bardziej interaktywny. Wykorzystamy teraz obiekt HttpServletRequest i na początek wyświetlimy na ekran wartość parametru testparam, który przyjdzie do serwletu metodą GET. Parametry wyjmujemy z żądania wywołując na nim metodę getparameter(), która zawsze zwraca wartość typu String, która reprezentuje pierwszą wartość parametru: Wynik wywołania dla poniższego adresu: 16/64
Pliki JSP, atrybuty żądania Łatwa generacja kodu HTML Generacja kodu HTML z poziomu serwletu nie jest zbyt wygodna. Stosujemy do tego pliki JSP (Java Server Pages). Pliki JSP znajdują się w katalogu Web Pages i tam je tworzymy. Są czymś pośrednim między zwykłymi plikami HTML, a serwletami. 17/64
Jak zdążyłeś/aś już zauważyć w kreatorze podajemy wyłącznie nazwę pliku JSP nie jest klasą Javy. Piszemy w nich zwykły HTML wzbogacony o tagi JSTL i język EL. Proces standardowo przebiega tak, że klasa controller a odbiera dane z warstwy DAO i przekazuje je do widoku (plikujsp), gdzie łatwo wygenerujemy kod HTML. Aby połączyć widok z controller em potrzebna będzie wiedza z kolejnego rozdziału. Mechanizm dispatcher a, atrybuty żądania - łączymy controller z widokiem Powoli zbliżamy się do napisania aplikacji webowej, która będzie służyć do operacji CRUD na jednej z encji bazodanowych. W Javie EE udostępniono serwletom mechanizm dispatcher a, który pozwala przekazać sterowanie z jednego serwletu do drugiego. Ponadto możemy do żądania dodawać atrybuty czyli jakieś obiekty, które będą dostępne dla kolejnego serwletu. Najczęściej dispatcher a używamy, aby przekazać dane do pliku JSP. Zdecydowanie lepiej wyjaśni to przykład: 18/64
W momencie wywołania serwletu do żądania zostanie dodany atrybut pod nazwą czas, a następnie serwlet przekaże sterowanie do pliku JSP (co wiąże się również z przekazaniem odpowiedzialności za wygenerowanie odpowiedzi). Przekazywać sterowanie za pomocą dispatcher a możemy tylko do serwletów (podając URL z którym są związane), albo do JSP (podając lokalizację pliku). Aby z poziomu JSP odwołać się do naszego atrybutu użyjemy języka EL (Expression Language). 19/64
Jak widać na warstwie widoku do przekazanych przez serwlet atrybutów odwołujemy się dokładnie po nazwie, pod którą zapisaliśmy obiekt w żądaniu. Samo wyświetlenie obiektu w pliku JSP nie różni się niczym od wywołania metody tostring() na danym obiekcie. Dużo ciekawsze jest odwołanie ${czas.time}. Wydawałoby się, że odwołujemy się do pola obiektu, ale w rzeczywistości wywoływana jest metoda gettime(). Pliki JSP potrafią dużo więcej, mianowicie uruchamiać pętle, wykonywać instrukcje warunkowe, a nawet formatować daty i liczby. Bardziej zaawansowane możliwości JSP zaprezentuję w artykule poświęconym tagom JSTL. WAŻNE! Jeśli kontroler uzyska dostęp do strumienia piszącego na ekran przeglądarki (response.getwriter()) nie będzie można użyć już dispatcher a. Dzieje się tak dlatego, że uzyskanie referencji do wspomnianego strumienia oznacza wzięcie przez metodę serwletu odpowiedzialności za wygenerowanie odpowiedzi HTTP. 20/64
Cykl życia serwletu i ich uruchamianie wraz ze startem serwera Cykl życia serwletu Umiemy już używać serwletów, ale dalej nie wiemy co dzieje się za sceną kiedy serwlet jest tworzony, a kiedy jego obiekt jest niszczony. Życie serwletu można podzielić na kilka faz: 21/64
Przyjrzymy się wywołaniom tych metod. Najpierw przygotuję odpowiednio klasę serwletu: 22/64
Po kilkukrotnym wyświetleniu strony (dokładnie tej samej tabelki z poprzedniego artykułu) w logach serwera widać dokładnie co się dzieje: Uruchamianie serwletu wraz ze startem serwera W aplikacjach webowych bardzo często funkcjonują scheduler y. Kod odpowiedzialny za uruchomienie cykliczne uruchamianie zadań nie powinien być uzależniony od konkretnego żądania, a jedynie od startu serwera. Pokażę teraz jak poinformować kontener serwletów aby uruchomił konkretne serwlety w momencie ładowania aplikacji, co więcej uruchomił je w zadanej kolejności. Najpierw stworzę trzy 23/64
serwlety Load1, Load2, Load3 i przesłonię w nich metodę init() w następujący sposób. Serwlety po prostu wyświetlają swoje numery w trakcie inicjacji (a będąc ścisłym - w momencie złączenia klasy serwletu z adresem URL). Poza tym, nie wprowadzałem w nich żadnych innych modyfikacji. Aby poinformować kontener serwletów o tym, że powyższe trzy mają zostać stworzone przy starcie serwera konieczna będzie edycja pliku web.xml. W tagu <servlet> umieszczam tag <load-on-startup>, który określa kolejność uruchamiania serwletu przy starcie serwera. Aby wszystko zadziałało prawidłowo wartość tagu <load-on-startup> musi być większa lub równa 0. W przeciwnym wypadku informacja zostanie przez kontener zignorowana. Konfiguracja pozostałych serwletów: 24/64
Oraz logi serwera w trakcie restartowania aplikacji: Tagi JSTL Tagi JSTL (JSP Standard Tags Library) pozwalają do plików JSP wprowadzić struktury charakterystyczne dla programów np. pętle. Zajmiemy się teraz wyświetleniem wszystkich pracowników w postaci tabelki. Odwołamy się do klasy EmployeesDao, która zwraca nam pracowników przechowywanych w bazie danych w postaci listy obiektów. Najwygodniej jest stworzyć w naszym serwlecie pole typu EmployeesDao: 25/64
Nie dzieje się tu nic specjalnego. Metoda getall() zwraca listę pracowników i przekazuje ją do widoku. W pliku JSP będziemy iterować po tej liście generując odpowiedni kod HTML. Przygotowuję najpierw schemat prostej tabelki: 26/64
Do uruchamiania struktur typowo programowych (np. pętli) służą tagi JSTL, są to specjalne biblioteki tagów, które dają możliwość tworzenia instrukcji warunkowych, formatowania liczb i dat. Mamy trzy podstawowe biblioteki tagów: core pozwala na tworzenie instrukcji warunkowych, pętli> functions uruchamianie funkcji np. trim(), sprawdzanie długości listy fmt formatowanie danych, obsługa ustawień internacjonalnych Użyjemy teraz biblioteki core. Aby mieć dostęp do tego co oferuje musimy ją najpierw zaimportować specjalną instrukcjątaglib: Napisanie pętli za pomocą tagów JSTL jest nawet prostsze niż w czystej Javie. 27/64
JSTL bardzo przypomina XML. Do tagów z biblioteki core odwołujemy się po prefiksie określonym w trakcie importu. Zbiór po którym będziemy iterować podajemy jako wyrażenie języka EL, a następnie określamy nazwę pojedynczego elementu w obrębie obrotu pętli. Jest to inny zapis dobrze znanej nam pętli for-each z Javy: Pozostał jeszcze atrybut varstatus. Określenie jego wartości pozwala na używanie numeru obrotu pętli ja użyłem tej wartości do wyświetlania numeru wiersza. Do pliku JSP dodałem jeszcze trochę CSS. Efektem wywołania powyższego serwletu jest poniższa strona: 28/64
29/64
Tag c:if najprostsza instrukcja warunkowa Do powyższej tabelki dodamy jeszcze jedną kolumnę tak by wykorzystać dwa kolejne tagi z biblioteki core tag c:if i c:choose. Wyświetlimy teraz informację o tym czy pracownik zarabia powyżej średniej. Muszę zatem dorzucić kolejny atrybut do żądania http wartość typu Double, która będzie reprezentować średnią zarobków. Obsłużymy teraz prosty warunek na warstwie widoku stosując tag c:if. Dodam do generowanej tabeli jeszcze jedną kolumnę: Oprogramowuję jej zawartość oczywiście wewnątrz pętli c:foreach. 30/64
Warunek do sprawdzenia to atrybut test tagu c:if. Warunek do sprawdzenia podaję jako wyrażenieel. Jeśli warunek jest spełniony zostanie wyświetlona zawartość tagu c:if. Jest to tylko pojedyncza instrukcja warunkowa za pomocą c:if nie ma możliwości wykonać znanego nam z Javy bloku if-else. Służy do tego tag c:choose, który omówimy w kolejnym rozdziale. 31/64
c:choose czyli bardziej złożone warunki Tak jak powiedziałem za pomocą tagu c:if nie napiszemy prostego bloku if-else. Służy do tego tag c:choose o bardziej złożonej strukturze: Za pomocą tagu c:choose tworzymy strukturę if-else if-else. Warunki sprawdzane są liniowo, przy czym pojedynczy warunek oznaczamy tagiem c:when sekcję else oznaczamy tagiem c:otherwise. W wyniku powyższych modyfikacji wywołanie serwletu da nam poniższy wynik: 32/64
Biblioteka fmt formatujmy nasze dane W bibliotece fmt zawarto tagi, które potrafią formatować liczby i daty. Znajdziemy tam również tagi odpowiedzialne za internacjonalizację plików JSP obsługę tzw. ResourceBundle i obiektów klasy Locale. Z oczywistych powodów najbardziej będą interesować nas tagi: fmt:formatdate fmt:formatnumber fmt:formatdate formatowanie dat Nazwa mówi sama za siebie. W zasadzie w tym małym rozdziale pokażę w zasadzie dwa tagi z biblioteki fmt. Zaczniemy od dodania formatowania daty zatrudnienia do powyższej tabeli. Robimy to za pomocą tagu fmt:formatdate w następujący sposób: Do atrybutu value przekazujemy obiekt typu Date jako wyrażenie EL. Spójrzmy na wynik: 33/64
Nic się nie zmieniło? Dzieje się tak dlatego, że Java wykryła parametry lokalizacyjne właściwe dla Polski i zastosowała je dla formatowania daty. Po dodaniu poniższego tagu w dowolnym miejscu przed formatowaniem, zostaną zastosowane ustawienia właściwe dla Francji. Zmiany widać od razu: Często jednak będziemy chcieli uniezależnić się od opcji lokalnych i zawsze wyświetlić datę w ten sam sposób. Musimy wtedy określić atrybut pattern tagu fmt:formatdate w następujący sposób: 34/64
W Javie miesiące oznaczamy jako duże MM! Tag fmt:formatnumer formatowanie liczb Liczby formatujemy za pomocą tagu fmt:formatnumber podobnie jak daty. Formatowanie liczb ma jednak więcej opcji dodatkowych: Atrybut minfractiondigits określa minimalną ilość miejsc dziesiętnych (analogiczniemaxfractiondigits). Do formatowania musimy także przekazać wartość jaką chcemy formatować ma ona znaleźć się w 35/64
atrybucie value. Dodatkowo możemy też podać czym jest dana liczba w atybucie type. Może przyjąć trzy wartości: number currency percentage Atrybut currencysymbol jest raczej oczywisty. Po wywołaniu efekt formatowania jest od razu widoczny: Regulowanie opcji lokalizacyjnych oczywiście dalej działa. Po przestawieniu Locale na enzobaczymy już tak sformatowane liczby: 36/64
Skryptlety - kod Javy w plikach JSP Nie powiedzieliśmy sobie o jeszcze jednej funkcjonalności plików JSP. Otóż możemy w nich używać całkowicie normalnej Javy. Wystarczy że gdzieś w pliku JSP użyjemy znaczników <% %> i w nich można już korzystać ze wszystkiego co daje nam Java. Np. dodam teraz wyświetlanie obecnej daty do formularza logowania, który stworzyłem na potrzeby poprzedniego przykładu: Klasa SimpleDateFormat to prosty formatter i parser dat pozwala na łatwe konwersje Date >> String i String >> Date. Taki blok kodu nazywamy skryptletem. Wywołanie JSP przedstawia poniższy screen: 37/64
W kodzie skryptletów mamy zdefiniowane ( a priori ) zmienne (to tylko niektóre z nich): request response out Stosowanie skryptletów jest uważane za nieeleganckie, ponieważ od sterowania widokiem są tagi JSTL. Niemniej jednak, jeśli istnieje potrzeba do zawarcia bardziej skomplikowanej logiki w warstwie widoku jest taka możliwość. 38/64
Obsługa formularzy w Javie Web Zajmiemy się teraz bardziej poważnym odbiorem danych od użytkownika. Wykonamy mianowicie aplikację pozwalającą na 39/64
operacie CRUD na encji bazodanowej Country. Kraj posiada tylko swój idenyfikator, nazwę i id regionu, które jest oczywiście kluczem obcym. Po przygotowaniu sobie klasy DAO do encji Country przystępuję do pisania serwletów. Encja Country wygląda tak: Być może zastanawiasz się dlaczego polem klasy Country jest obiekt Region, a nie regionid. Przy takim układzie mój obiekt Country będzie bardziej elastyczny. Mogę w nim zapisać zarówno samo id regionu, jak również całą strukturę Regionu nazwę etc. Pierwszy serwlet będzie odpowiadał oczywiście za wyświetlenie danych w postaci tabeli: 40/64
Tym razem zdecydowałem się na konfigurację serwletu za pomocą adnotacji @WebServlet. W samym serwlecie nie dzieje się nic, czego byśmy wcześniej nie omawiali. Warstwa widoku jest podobnie prosta: Dodałem od razu kolumnę Actions w której znajdują się dwa linki prowadzące do serwletu, który skasuje dany kraj i formularza z Edycją danego kraju. Muszę oczywiście podać informację o tym, na rzecz którego kraju ma zostać wywołana akcja. Dlatego przekazuję parametr id metodą GET (po linku). Dołączyłem do powyższego przykładu bibliotekę CSS - Bootstrap, dlatego uzyskuję ładnie sformatowaną tabelkę: 41/64
Zajmiemy się teraz formularzem edycji. Najpierw tworzę serwlet, którego URL Pattern odpowiada temu z linka: Zawartość parametru id oczywiście bierze się z adresu URL (np. editcountry.do?id=nl). Być może zastanawia Cię, po co przekazuję na widok również wszystkie regiony z bazy danych. Relacja między encją Region, a Country w bazie danych to jeden-wiele, dlatego jeden 42/64
konkretny region, który przyporządkujemy do kraju wybierzemy z selektora. Przystępuję do pisania formularza: Wątpliwości mogą budzić dwie rzeczy. Po pierwsze nie określam atrybutu action tagu form, ponieważ będę przekazywał dane do tego samego URL. Po drugie c:if w c:foreach. Spowoduje on automatyczne wybranie z listy regionu, do którego przypisany został kraj. OK. Zobaczmy jak to wygląda: 43/64
Pozostaje nam już tylko oprogramować metodę dopost() naszego serwletu. Na początek obejrzyjmy jakie informacje znajdują się w obiekcie HttpServletRequest. Tak jak z request a wyjmowaliśmy pojedynczy parametr tak samo możemy wyjąć wszystkie w postaci mapy <String, String[]> po której zwyczajnie przeiterujemy. Po zatwierdzeniu formularza uzyskuję w przeglądarce poniższy output: Zauważ, że z poziomu metody dopost() mamy dostęp zarówno do parametrów przesłanych metodą GET jak i do tych przesłanych POST em. Wystarczy, że z powyższych danych złożę obiekt i podam go warstwie DAO do zapisania w bazie: 44/64
OK. Tak to wygląda. Być może uważasz, że komplikuję sprawę ponad miarę try-catchem. Nie zapominaj jednak, że użytkownik może edytować źródło strony a także o tym, że parametr ID jest przekazywany przez pasek. Temu właśnie służy try-catch najpierw sprawdzam czy do edycji podano prawidłowe dane (czy to, co miało być liczbą rzeczywiście nią jest), a także, czy referencje podane przez formularz (id regionu, id kraju) mają jakieś odzwierciedlenie w bazie danych. Dopiero po spełnieniu tych dwóch warunków przystępuję do złożenia obiektu Country, zapisania go w bazie danych i 45/64
poinformowania formularza, że edycja przebiegła pomyślnie. Dodatkowo w widoku dodaję nad polami formularza poniższy wpis: Jest to wyświetlenie informacji o poprawnej edycji (w języku EL sprawdzenie czy jakiś atrybut został przekazany realizujemy instrukcją not empty). Po poprawnej edycji jakiegoś kraju dostanę oczywiście powiadomienie: Wszystko działa dokładnie tak jak chcieliśmy. Oczywiście przydałaby się jeszcze jakaś walidacja danych, ale nie robiłem tego aby nie zaburzać czytelności przykładu. Podpowiem tylko, że walidację danych najlepiej wydzielić do oddzielnej metody przyjmującej jakiś obiekt i ew. wpisującej błędy do mapy, do której później odwołamy się za pomocą EL. 46/64
Kontener serwletów Tomcat 7 Instalacja Tomcat 7 Zajmiemy się teraz jednym z najczęściej używanych kontenerów webowych czyli Tomcat a. Jest to oprogramowanie serwerowe, na które będziemy deploy ować nasze aplikacje. Zaczniemy oczywiście od instalacji i skonfigurowania Tomcat a. Aby pobrać pliki Tomcat 7 musimy wejść na stronę projektu - https://tomcat.apache.org/download70.cgi: 47/64
Interesować nas będą oczywiście opcje pobrania Tomcat 7: Wybierzemy pierwszą opcja czyli pobranie paczki niezależnej platformowo, gdzie wszystko już się znajduje. Nie polecam instalowania Tomcat a jako usługi systemowej Windows. Jego używanie jest wtedy dość niewygodne. Po pobraniu zip a wypakowuję jego zawartość do folderu C:/tomcat7/. Cała struktura serwera to kilka folderów: 48/64
folder /bin/ - w nim znajdują się pliki wykonywalne odpowiedzialne za m.in. startowanie i zamykanie serwera. folder /conf/ zawiera pliki konfiguracyjne serwera w większości XML folder /lib/ - biblioteki niezbędne do poprawnego działania serwera i aplikacji folder /logs/ - logi serwera folder /webapps/ - tu będziemy najczęściej zaglądać. Znajdują tam się zainstalowane aplikacje webowe folder /work/ - serwer umieszcza tu skompilowane wersje plików JSP, pliki cache'a (np. schematy XML) 49/64
Pierwsze uruchomienie kontenera Tomcat Aby uruchomić serwer Tomcat wystarczy uruchomić plik startup.bat, który znajduje się w katalogu /bin/. Zapewne zauważyłeś/aś, że Tomcat wystartował i zaraz jego działanie zostało przerwane. Dzieje się tak dlatego że Tomcat wymaga zdefiniowania zmiennej środowiskowejcatalina_home, która przechowuje ścieżkę do instalacji Tomcat a.: Teraz po uruchomieniu startup.bat wyskoczy okno z logami serwera. 50/64
Jeśli zobaczyłeś/aś powyższy ekran, po wpisaniu adresu http://localhost:8080 powinien przywitać Cię charakterystyczny dla Tomcat a tygrysek: 51/64
Uruchomienie Tomcat7 na systemie Linux Mint Jeśli używasz systemu Linux to, masz dwie możliwości zainstalowania Tomcat a. Możesz zainstalować go jako usługę systemową komendą: sudo apt-get install tomcat7 Wtedy niestety, pliki Tomcat a zostaną rozbite na kilka lokacji (/usr/share/, /var/lib/ etc.). Możesz też, ściągnąć Tomcat a jako multiplatformowego zip-a (dokładnie tak samo jak na Windowsie). Resztę konfiguracji zawarłem już w screen ie z terminala na następnej stronie. Folder tomcat7 znajduje się w moim katalogu home. Niestety na Liunux ach nie mamy okienka z logami serwera, ale można je sobie ładnie zastąpić używając poniższej komendy (oczywiście ścieżka do pliku catalina.out zależy od Twojej instalacji): tail f /home/kamil/tomcat7/logs/catalina.out 52/64
Instalacja na Linux ie Mint różni się jedynie tym, że muszę odpowiednio przyznać uprawnienia do wykonywania plików. Służy do tego komenda chmod. Uprawnienia domyślne (chmod 644) widać oczywiście przy pierwszym wykonaniu ls l head -5. Pamiętaj o zmiennej CATALINA_HOME! Uruchamianie Tomcat'a na innych linuksach (np. CentOS) zależy już od konkretnej dystrybucji i zwykle nie jest tak proste. 53/64
Instalowanie aplikacji webowej na Tomcat 7 Instalacja Tomcat 7 Zajmiemy się teraz jednym z najczęściej używanych kontenerów webowych czyli Tomcat a. Jest to oprogramowanie serwerowe, na które będziemy deploy ować nasze aplikacje. Zaczniemy oczywiście od instalacji i skonfigurowania Tomcat a. Aby pobrać pliki Tomcat 7 musimy wejść na stronę projektu - https://tomcat.apache.org/download70.cgi: 54/64
Interesować nas będą oczywiście opcje pobrania Tomcat 7: Wybierzemy pierwszą opcja czyli pobranie paczki niezależnej platformowo, gdzie wszystko już się znajduje. Nie polecam instalowania Tomcat a jako usługi systemowej Windows. Jego używanie jest wtedy dość niewygodne. Po pobraniu zip a wypakowuję jego zawartość do folderu C:/tomcat7/. 55/64
Cała struktura serwera to kilka folderów: folder /bin/ - w nim znajdują się pliki wykonywalne odpowiedzialne za m.in. startowanie i zamykanie serwera. folder /conf/ zawiera pliki konfiguracyjne serwera w większości XML folder /lib/ - biblioteki niezbędne do poprawnego działania serwera i aplikacji folder /logs/ - logi serwera folder /webapps/ - tu będziemy najczęściej zaglądać. Znajdują tam się zainstalowane aplikacje webowe folder /work/ - serwer umieszcza tu skompilowane wersje plików JSP, pliki cache'a (np. schematy XML) 56/64
Pierwsze uruchomienie kontenera Tomcat Aby uruchomić serwer Tomcat wystarczy uruchomić plik startup.bat, który znajduje się w katalogu /bin/. Zapewne zauważyłeś/aś, że Tomcat wystartował i zaraz jego działanie zostało przerwane. Dzieje się tak dlatego że Tomcat wymaga zdefiniowania zmiennej środowiskowejcatalina_home, która przechowuje ścieżkę do instalacji Tomcat a.: Teraz po uruchomieniu startup.bat wyskoczy okno z logami serwera. 57/64
Jeśli zobaczyłeś/aś powyższy ekran, po wpisaniu adresu http://localhost:8080 powinien przywitać Cię charakterystyczny dla Tomcat a tygrysek: Uruchomienie Tomcat7 na systemie Linux Mint Jeśli używasz systemu Linux to, masz dwie możliwości zainstalowania Tomcat a. Możesz zainstalować go jako usługę systemową komendą: sudo apt-get install tomcat7 Wtedy niestety, pliki Tomcat a zostaną rozbite na kilka lokacji (/usr/share/, /var/lib/ etc.). Możesz też, ściągnąć Tomcat a jako multiplatformowego zip-a (dokładnie tak samo jak na Windowsie). Resztę konfiguracji zawarłem już w screen ie z terminala na następnej stronie. Folder tomcat7 znajduje się w moim katalogu home. Niestety na Liunux ach nie mamy okienka z logami serwera, ale można je sobie 58/64
ładnie zastąpić używając poniższej komendy (oczywiście ścieżka do pliku catalina.out zależy od Twojej instalacji): tail f /home/kamil/tomcat7/logs/catalina.out Instalacja na Linux ie Mint różni się jedynie tym, że muszę odpowiednio przyznać uprawnienia do wykonywania plików. Służy do tego komenda chmod. Uprawnienia domyślne (chmod 644) widać oczywiście przy pierwszym wykonaniu ls l head -5. Pamiętaj o zmiennej CATALINA_HOME! Uruchamianie Tomcat'a na innych linuksach (np. CentOS) zależy już od konkretnej dystrybucji i zwykle nie jest tak proste. 59/64
Korzystanie z Tomcat7 w NetBeans i zmiana portu nasłuchu Tomcat7 Na potrzeby tego rozdziału stworzę nowy projekt. Nowy serwer dodamy po drodze. Procedurę dodawania projektu już znasz, ale zatrzymamy się przy przedostatnim oknie. W zakładce Server and Settings wybieramy opcję Add (obok selektora z domyślnie wybranym GlassFish em). Następnie z listy wybieramy pozycję Apache Tomcat or TomEE. Wychodzę na poniższe okno: W Server Location musimy podać lokalizację serwera Tomcat (dokładnie taką samą jak w zmiennej CATALINA_HOME). W Username i Password podajemy w zasadzie cokolwiek. Aby aplikacja mogła deployo wać paczki na serwerze (a dokładnie wykonywać hotdeploy czyli instalację appki w czasie działania serwera) potrzebuje specjalnego użytkownika w obrębie serwera. 60/64
Definicje użytkowników i ich ról znajdują się w pliku /conf/tomcatusers.xml w katalogu Tomcat a przyjrzymy mu się jeszcze później. Po dodaniu nowego projektu i uruchomieniu go uzyskamy poniższy Output: Jest to błąd w samym Tomcat cie (a dokładnie w pliku catalina.bat) na szczęście łatwy do poprawienia. Wystarczy zmienić w nim linijki 179 i 184: Do poniższej postaci (chodzi o usunięcie cudzysłowów w obu linijkach): 61/64
OK. Spróbujmy jeszcze raz uruchomić Tomcat a z poziomu NetBeans: Wszystko działa tak jak powinno. na Linuksach powyższy problem nie występuje. 62/64
Uruchomienie Tomcat'a na porcie 80 Chciałbym jeszcze pokazać kilka rzeczy, które sprawią, że rozwijanie aplikacji będzie wygodniejsze. Wykonamy dwie rzeczy. Przepniemy port Tomcata z 8080 do domyślnego portu HTTP czyli 80. Muszę zmienić wpis o porcie wykorzystywanym przez serwer w pliku conf/server.xml. Wystarczy zmienić atrybut port na 80 (i oczywiście zrestartować serwer), a Tomcat będzie dostępny już bez podawania portu: 63/64
Oczywiście jest to najprostsza procedura. Na różnych systemach operacyjnych może ona wyglądać inaczej. Np. na Linuksach często trzeba dodatkowo odblokować port firewall'a, a czasem nawet za pomocą iptables przekierowywać ruch sieciowy na portach. Z kolei nie można tego wykonać na Windows 10 ponieważ port 80 jest zarezerwowany przez system. 64/64