W tym rozdziale:

• Podstawy HTTP

• Interfejs API (Servlet API)

• Tworzenie strony

• Aplikacje WWW

• Przejdźmy dalej

Rozdział 2.

Aplety Http — wprowadzenie

Ten rozdział to krótki samouczek pisania i uruchamiania prostych apletów HTTP.

Opisane tutaj zostanie jak wdrożyć aplet do standardowej aplikacji WWW i jak skonfigurować jego zachowanie przy użyciu XML-owego deskryptora rozmieszczenia.

W przeciwieństwie do pierwszej edycji niniejszej książki, ten rozdział obecnej nie opisuje opartych na apletach plików dołączanych serwera (SSI) lub wiązania łańcuchowego oraz filtrowania apletu. Mimo tego, iż techniki te były bardzo przydatne oraz zostały umieszczone w serwerze WWW (Java Web Server), nie zostały zatwierdzone w specyfikacji apletu, (która ukazała się po pierwszej edycji niniejszej pozycji). SSI zostały zastąpione przez nowe techniki tworzenia plików dołączanych programu. Wiązanie łańcuchowe apletu zostało uznane za zbyt nieczytelne dla oficjalnego zatwierdzenia, mimo tego jest wielce prawdopodobne, że sama jego idea zostanie wykorzystana w Interfejsie API 2.3 (Servlet API 2.3) jako część oficjalnego mechanizmu ogólnego zastosowania przed i po — filtrującego.

Zwróćmy uwagę, iż możliwe jest ściągnięcie kodów dla każdego z przykładów zamieszczonych w tym oraz innych rozdziałach tej książki, zarówno w formie źródłowej jak i skompilowanej (jak zostało to opisane w przedmowie). Jednakże, co się tyczy tego rozdziału, wydaje się, iż rzeczą najbardziej pomocną w nauce będzie zapisanie przykładów ręcznie (za pomocą klawiatury). Lektura tego rozdziału może prowadzić do wniosku, iż niektóre zagadnienia zostały potraktowane zbyt ogólnie. Aplety to narzędzia dające wiele możliwości i czasem bywają skomplikowane, dlatego też rozdział ten ma na celu wprowadzenie w ogólne zasady ich działania i zorientowania się w temacie. Czytelnik po lekturze niniejszej książki będzie w stanie samodzielnie tworzyć najrozmaitsze aplety.

Podstawy HTTP

Zanim przejdziemy do omawiania prostych apletów HTTP, musimy sprawdzić znajomość podstaw działania protokołu HTTP. Będąc doświadczonym w programowaniu w CGI (lub mając doświadczenie w tworzeniu stron WWW na serwerach) można z powodzeniem pominąć czytanie tego podrozdziału. W takim przypadku korzystnym wydaje się zatrzymanie się na istotnych zagadnieniach metod GET i POST. Jednakże będąc osobą stawiającą pierwsze kroki w tworzeniu stron WWW na serwerach, należy przeczytać wspomniany materiał uważnie, ponieważ zrozumienie dalszej części książki wymaga znajomości protokołu HTTP. Protokół HTTP został szczegółowo omówiony w --> „Pocket Reference” Clintona Wong'a (wydawnictwo O'Reilly)[Author:PG] .

Zlecenia, odpowiedzi, nagłówki

HTTP jest prostym, międzynarodowym protokołem. Klient, np. przeglądarka WWW składa zlecenie, serwer WWW odpowiada i dokonywana jest tzw. „obsługa zlecenia”. Kiedy klient składa zlecenie, pierwszą rzeczą którą wykonuje, jest komenda HTTP zwana metodą, za pomocą której serwer orientuje się jaki rodzaj zlecenia jest składany. Pierwszy wiersz zlecenia określa adres dokumentu (URL) oraz używaną wersję protokółu HTTP. Oto przykład:

GET/intro.html Http/1.0

W tym zleceniu chodzi o uzyskanie dokumentu o nazwie intro.html za pomocą wersji 1.0 HTTP. Po przesłaniu zlecenia klient może przesłać informacje nagłówkową w celu dostarczenia serwerowi dodatkowych informacji o zleceniu, takich jak: jakie oprogramowanie jest używane przez klienta oraz jaka forma informacji potrzebna jest klientowi do jej zrozumienia. Takie informacje nie odnoszą się bezpośrednio do tego, co było przedmiotem zlecenia, jednakże mogą być wykorzystane przez serwer w tworzeniu odpowiedzi. Oto dwa przykłady nagłówków zleceń:

User-Agent : Mozilla/4.0 (compatabile; MSIE 4.0; Windows 95)

Accept : image/gif, image/jpeg, text/*, */*

Nagłówek User-Agent dostarcza informacji o oprogramowaniu klienta, podczas gdy nagłówek Accept określa rodzaj nośnika (MIME) najkorzystniejszy dla klienta (nagłówki zleceń zostaną omówione szerzej przy omawianiu apletów, w rozdziale 4 „Odczytywanie informacji”). Celem zaznaczenia końca sekcji nagłówkowej, po przesłaniu nagłówków, klient przesyła nie zapisany wiersz. Jeżeli wymaga tego używana metoda, klient może również przesłać inne dodatkowe dane, tak jak w przypadku metody POST, która zostanie zaraz omówiona. Jeżeli zlecenie nie zawiera żadnych danych, to kończy się nie zapisanym wierszem. Po przesłaniu przez klienta zlecenia, serwer przetwarza je i przesyła odpowiedź. Pierwszy wiersz odpowiedzi zawiera wiersz statusu oraz jego opis. Oto przykład:

HTTP/1.0 200 OK.

Powyższy wiersz statusu zawiera kod statusu 200, co oznacza że zlecenie zostało wykonane, stąd opis OK. Kolejny często spotykany kod to 404 z opisem Not Found (nie znaleziono), jak łatwo się domyśleć opis ten oznacza, że dokument nie został odnaleziony. W rozdziale 5 „Przesyłanie informacji HTML” zostały omówione najczęściej spotykane kody statusu oraz w jaki sposób można je wykorzystać w apletach. --> Dodatek D „Kody statusu HTTP[Author:PG] ” zawiera kompletną listę kodów statusu HTTP. Po przesłaniu wiersza statusu serwer przesyła nagłówki odpowiedzi, które są informacją dla klienta taką jak np.: jakiego oprogramowania używa serwer oraz nośnika informacji użytego do zapisania odpowiedzi serwera. Oto przykład:

Date: Saturday, 23-May-00 03:25:12 GMT

Server: Tomcat Web Server/3.2

MIME-version:1.0

Content-type: text/html

Content-length: 1029

Last-modified: Thursday, 7-May-00 12:15:35 GMT

Nagłówek Server dostarcza informacji o oprogramowaniu serwera, nagłówek Content-type określa rodzaj rozszerzenia MIME odnośnie danych zawartych w odpowiedzi (nagłówki odpowiedzi zostaną omówione szerzej w rozdziale 5). Po nagłówkach serwer przesyła „czysty wiersz” celem zakończenia sekcji nagłówkowej. Jeżeli zlecenie zostało wykonane, żądane dane są następnie przesyłane jako część odpowiedzi. W przeciwnym wypadku odpowiedź może zawierać informację tekstową dla osoby obsługującej przeglądarkę, która będzie wyjaśniała dlaczego serwer nie mógł wykonać zlecenia.

Metody GET i POST

Klient łącząc się z serwerem może złożyć zlecenie w kilku różnych formach, zwanych metodami. Najczęściej używane metody to GET i POST. Metoda GET służy do uzyskiwania informacji (dokumentów, wykresów, informacji bez danych), podczas, gdy metoda POST została zaprojektowana z myślą o wysyłaniu informacji (numerów kart kredytowych, danych statystycznych lub informacji baz danych). Wykorzystując analogię elektronicznego biuletynu informacyjnego, GET służy do czytania a POST do zamieszczania w nim tekstu. GET to metoda używana do wprowadzania URL-u bezpośrednio do przeglądarki lub podczas klikania na hiperlink; jednakże zarówno metoda GET jak i POST mogą być używane do dostarczania formularzy HTML.

Mimo, iż metoda GET została zaprojektowana w celu odczytywania informacji, może zawierać jako część zlecenia informacje własne, które dokładniej precyzują to zlecenie. Może to być np. układ współrzędnych x,y dla wykresów. Takie informacje są przesyłane jako ciąg znaków dołączonych do URL-u w formie znanej ciągiem zapytań. Ten sposób zamieszczania dodatkowych informacji w URL-u umożliwia przesłanie strony e-mailem bądź utworzenie z niej zakładki. Ponieważ zlecenia GET nie są przeznaczone do przesyłania dużych partii informacji, niektóre serwery ograniczają długość URL-ów i ciągów zapytań do około 240 znaków.

W metodzie POST używana jest odmienna technika przesyłania informacji do serwera, ponieważ niekiedy metody tej używa się do przesyłania większych partii informacji. Zlecenie złożone za pomocą metody POST przesyła bezpośrednio wszystkie informacje (nie ograniczone co do długości) w nim zawarte za pomocą połączenia gniazdowego jako część swego zlecenia HTTP. Klient nie jest informowany o tej zamianie, URL nie ulega w ogóle zmianie. W efekcie zlecenia POST nie mogą być ani zapisane jako zakładki, ani wysłane e-mailem, ani też w niektórych przypadkach nie mogą być w ogóle powtórnie załadowane. Powód jest prosty — sytuacja taka wynika z odpowiedniego zaprojektowania — informacja jak np. numer naszej karty kredytowej, powinna być przesyłana do serwera tylko raz. Stosując metodę POST uzyskujemy dodatkowo pewien stopień zabezpieczenia przy przesyłaniu poufnych informacji, ponieważ dziennik zdarzeń, który zapisuje wszystkie zgłoszenia URL-ów, nie rejestruje danych metody POST.

W praktyce użycie metod GET i POST odbiega od celu, dla którego zostały zaprojektowane. Powszechną praktyką przy składaniu długich parametryzowanych zleceń na informacje jest użycie POST zamiast GET w celu uniknięcia problemów związanych z nadmiernie długimi URL-ami. Metoda GET jest również często wykorzystywana do ładowania informacji przez proste formularze ponieważ, no cóż, po prostu da się to w ten sposób zrobić. Powyższe problemy nie są jednak aż tak dramatyczne, wystarczy tylko pamiętać, iż zlecenia GET (z powodu tego, iż mogą być w prosty sposób zamieniane na zakładki) mogą wywołać zmianę na serwerze, za którą odpowiedzialny będzie klient. Chodzi o to, że zlecenia GET nie powinny być używane do składania zleceń, uaktualniania baz danych oraz do innych działań umożliwiających identyfikację klienta (w przypadku wystąpienia zmian na serwerze).

Pozostałe metody Http

Poza GET i POST istnieje jeszcze wiele, rzadziej używanych metod HTTP, takich jak na przykład metoda HEAD. Metoda ta jest używana przez klienta tylko do uzyskiwania nagłówków odpowiedzi, w celu określenia rozmiaru dokumentu, czasu modyfikacji lub ogólnej dostępności. Inne metody to PUT — do zamieszczania dokumentów bezpośrednio na serwerze, DELETE — wykorzystywana do ich usuwania stamtąd. Dwie ostatnie metody nie współpracują ze wszystkimi serwerami z powodu skomplikowanych procedur. Metoda TRACE jest powszechnie używana do usuwania błędów — umożliwia przesłanie klientowi dokładnej treści jego zlecenia. Metoda OPTIONS może być użyta do zapytania serwera, z którymi metodami współpracuje lub jak dotrzeć do poszczególnych jego zasobów.

Interfejs API (Servlet API)

Po zapoznaniu się z podstawami HTTP, możemy przejść do omówienia interfejsów API, których z kolei używa się do tworzenia apletów HTTP, lub innych rodzajów apletów odpowiednich dla tej materii. Aplety używają klas i interfejsów z dwóch pakietów: javax.servlet i javax.servlet.http. Pakiet javax.servlet zawiera klasy i współpracuje ze standardowymi protokołowo-niezależnymi apletami. Klasy te są rozszerzane przez klasy w pakiecie java.servlet.http w celu dodania funkcjonalności specyficznej dla HTTP. Pakiet najwyższej klasy nazywa się javax zamiast zwykłego java, aby zasygnalizować, iż Interfejs API jest pakietem dodatkowym (uprzednio zwanym Standardowym Rozszerzeniem). Każdy aplet musi wdrożyć interfejs javax.servlet. Większość apletów wdraża ten interfejs przez rozszerzenie jednej z dwóch specjalnych klas: javax.servlet.GenericServlet lub javax.servlet.http.HttpServlet. Aplet niezależny protokołowo powinien być podrzędny do GenericServlet, a aplet HTTP powinien być podrzędny w stosunku do HTTPservlet, który sam jest podklasą GenericServlet z dodana funkcjonalnością HTTP.

W przeciwieństwie do zwykłego programu Java, i dokładnie tak jak zwykły aplet, aplet wykonywany na serwerze nie zawiera metody main(). Zamiast tego pewne metody apletów wywoływane są przez serwer w procesie obsługi zleceń. Za każdym razem, kiedy serwer wysyła zlecenie do apletu, wywołuje jego metodę service().

Standardowy aplet w celu poprawnej obsługi zlecenia powinien zignorować swoją metodę service(). Metoda service() akceptuje dwa parametry: obiekt zlecenia i obiekt odpowiedzi. Obiekt zlecenia informuje aplet o zleceniu, a obiekt odpowiedzi używany jest do wysyłania odpowiedzi. Rysunek 2.1. ukazuje jak standardowy aplet obsługujący zlecenie.

Rysunek 2.1. Standardowy aplet obsługujący zlecenie

Aplet HTTP zwykle nie ignoruje metody service(), tylko metodę doGet() (do obsługi zleceń GET) i metodę doPost() (do obsługi zleceń POST). Aplet HTTP może zignorować jedną z powyższych metod lub obie, w zależności od tego, jaki jest typ zlecenia, które ma obsłużyć. Metoda service() HttpServlet obsługuje instalację oraz transfer do wszystkich metod doXXX(), dlatego właśnie zwykle nie powinna być ignorowana. Na rysunku 2.2 został ukazany sposób, w jaki aplet HTTP obsługuje zlecenia metod GET i POST.

Rysunek 2.2. Aplet HTTP obsługujący zlecenia GET i POST

Aplet HTTP może zignorować odpowiednio metody doPut() i doDelete() celem obsłużenia zleceń PUT i DELETE. Jednakże aplety HTTP generalnie nie modyfikują metod doTrace() czy doOptions(). Dla nich prawie zawsze wystarczające są implementacje domyślne.

Pozostałe klasy w pakietach javax.servlet i javax.servlet.http to w większości klasy wspomagające. Na przykład klasy ServletRequest i ServletResponse w javax.servlet umożliwiają dostęp do zleceń i odpowiedzi standardowych serwerów, natomiast klasy HttpServletRequest i HttpServletResponse w javax.servlet.http umożliwiają dostęp do zleceń i odpowiedzi HTTP. Pakiet javax.servlet.http zawiera również klasę HttpSession, która oferuje wbudowaną funkcjonalność śledzenia sesji oraz klasę Cookie, która pozwala na szybkie instalowanie i przetwarzanie cookies.

Tworzenie strony

Najbardziej podstawowy typ apletu HTTP tworzy pełną stronę HTML. Taki aplet ma zwykle dostęp do takich samych informacji, co przesyłane do skryptu CGI oraz do pewnej partii innych. Aplet, który tworzy strony HTML może zostać użyty do wykonywania wszystkich zadań, tych które obecnie są wykonywane przy pomocy CGI, jak np. przetwarzanie formularzy HTML, tworzenie listy z bazy danych, przyjmowanie zamówień, sprawdzanie zamówień, sprawdzanie identyfikacji, itd.

Pisanie „Hello World”

Przykład 2.1 ukazuje aplet HTTP tworzący kompletną stronę HTML. Dla uproszczenia sprawy aplet ten ,za każdym połączeniem się z nim za pomocą przeglądarki WWW, wyświetla napis „Hello World”.^*

Przykład 2.1. Aplet, który wyświetla „Hello World”

import java.io.*;

import javax.servlet.*;

import javax.servlet.http.*;

public class HellWorld extends HttpServlet {

public void doGet (HttpServletRequest req, HttpServletResponse res)

throws ServletException, IOException {

res.setContentType ("text/html");

PrintWriter out = res.getWriter ( );

out.println("<HTML>");

out.println("<HEAD><TITLE>Hello World</TITLE></HEAD>");

out.println ("<BODY>") ;

out.println (<BIG>Hello World</BIG>");

out.println ("</BODY><HTML>");

}

}

Powyższy aplet rozszerza klasę HttpServlet oraz ignoruje odziedziczoną z niej metodę doGet(). Kiedy serwer WWW otrzymuje zlecenie GET z tego apletu, każdorazowo wywołuje metodę doGet(), przekazując mu obiekty HttpServletRequest oraz HttpServletResponse. Obiekt HttpServletRequest reprezentuje zlecenie klienta. Obiekt ten daje apletowi dostęp do informacji o kliencie, parametrach zlecenia, nagłówkach HTTP przekazywanych razem ze zleceniem oraz inne. W rozdziale 4. omówione zostały wszystkie możliwości obiektu zlecenia. Dla tego przykładu możemy jednak je pominąć jako, ze niezależnie od typu zlecenia aplet ten wyświetla „Hello World”.

Obiekt HttpServletResponse reprezentuje odpowiedź apletu. Aplet może wykorzystać ten obiekt do dostarczenia danych klientowi. Mogą to być dane różnego typu, typ ten jednak powinien być określony jako część odpowiedzi. Aplet może również użyć tego obiektu do ustalenia nagłówków odpowiedzi HTTP. W rozdziałach 5. i 6 „Przesyłanie treści multimedialnej” zostało omówione wszystko co może zrobić aplet jako część odpowiedzi.

Nasz aplet ustala najpierw za pomocą metody setContentType() typ zawartości swojej odpowiedzi do text/html, standardowego typu zawartości MIME dla stron HTML. Następnie używa metody getWriter() w celu odczytania PrintWriter, międzynarodowego odpowiednika PrintStream. PrintWriter przekształca kod UNICODE Javy na kodowanie specyficzne lokalnie. Dla kodowania lokalnego — angielskiego zachowuje się tak jak PrintStream. Aplet używa wreszcie PrintWriter do wysłania swojego HelloWorld HTML do klienta.

Uruchamianie „Hello World”

Do tworzenia apletów potrzebne są dwie rzeczy: pliki klasy interfejsu API, które używane są w tłumaczeniu programu źródłowego na język wynikowy oraz pojemnik apletu np. serwer WWW, który używany jest z kolei przy uruchamianiu apletów. Wszystkie popularne pojemniki apletów oferują pliki klasy Interfejsu API, więc można spełnić oba warunki (potrzebne do tworzenia apletów) za jednym ładowaniem.

Istnieją dziesiątki parametrów dostępnych pojemników apletów dla wdrażania apletów, kilkanaście z nich zostało zamieszczonych w rozdziale 1 „Wprowadzenie”. Dokonując wyboru serwera należy pamiętać, że musi on współpracować z wersją 2.2 Interfejsu API (Servlet API 2.2) lub późniejszą. Wersja 2.2 była pierwszą wersją Interfejsu API, która zapewniała dostęp do aplikacji WWW, jak zostało to omówione w tym rozdziale. Aktualna lista pojemników apletów oraz tego do jakiego poziomu API zapewniają one dostęp i jest dostępna pod adresem: http://www.servlets.com.

Tak więc zapytajmy, co należy zrobić z naszym kodem, aby zadziałał w serwerze WWW? — to zależy od rodzaju serwera. W przykładach zaprezentowanych w tej książce występuje serwer „Apache Tomcat 3.2”, serwer implementacji odniesienia API, napisany całkowicie w Javie, dostępny pod adresem: http://jakarta.apache.org. Serwer „Tomcat” zawiera mnóstwo dokumentacji, w której jest wyjaśnione jego zastosowanie. W niniejszej książce dlatego właśnie omówione zostaną tylko ogólne zasady dotyczące pracy z serwerem. Poniższe omówienia powinny być także zgodne z innymi serwerami (niż „Tomcat”) jednakże nie można tego zagwarantować.

Jeżeli używamy serwera „Apache Tomcat”, to powinniśmy umieścić kod źródłowy dla apletu w katalogu server_root/webapps/ROOT/WEB-INF/classes (gdzie server_root jest katalogiem , w którym zainstalowaliśmy nasz serwer), jest to standardowa lokalizacja plików klasy apletu. Powód, dla którego aplety występują w tym katalogu zostanie omówiony później w tym rozdziale.

Kiedy już mamy właściwie umiejscowiony kod źródłowy HelloWorld, musimy go skompilować. To zadanie możemy wykonać przy pomocy standardowego kompilatora javac (lub naszego ulubionego środowiska graficznego Javy). Należy się tylko upewnić, że mamy pakiety javax.servlet i javax.servlet.http w naszej ścieżce klasy. Pracując z serwerem „Tomcat”, wystarczy tylko zamieścić server_root/lib/servlet.jar (lub przyszły odpowiednik) gdzieś w naszej ścieżce klasy. Nazwa pliku oraz lokalizacja zależą od serwera, więc w razie problemów trzeba zajrzeć do dokumentacji serwera, z którym mamy do czynienia. Jeżeli wyświetlony zostanie komunikat informujący o błędzie taki jak np. Package javax.server not found in import, oznacza to, że pakiety apletów nie są odnajdywane przez nasz kompilator, należy więc sprawdzić nasza ścieżkę klasy i spróbować jeszcze raz.

Teraz, kiedy już skompilowaliśmy nasz pierwszy aplet, możemy uruchomić nasz serwer i wejść do apletu. Uruchomienie serwera nie jest rzeczą trudną, należy uaktywnić skrypt startup.sh (lub plik startowy startup.bat w Windows) znajdujący się w katalogu server_root/bin.

To powinno wystarczyć do uruchomienia naszego serwera, jeżeli pracujemy w Solairs lub w Windows. W przypadku pracy na innych systemach operacyjnych może zdarzyć się sytuacja, że będziemy musieli dokonać pewnych modyfikacji w skryptach startowych. W przypadku konfiguracji domyślnych, serwer oczekuje na porcie 8080.

Istnieje wiele sposobów dostępu do apletów. Dla przykładu możemy zrobić to przez wyraźne wprowadzenie do URL-u nazwy klasy apletu. Możemy wprowadzić URL do swojej ulubionej przeglądarki:http://server:8080/servlet/HelloWorld. Wyraz server zamieniamy na nazwę naszego komputera — serwera lub na localhost — jeżeli serwer jest na naszym lokalnym komputerze. Powinna zostać wyświetlona strona podobna do tej poniżej.

Rysunek 2.3. Aplet „HelloWorld”

Jeżeli aplet byłby częścią pakietu musiałby zostać umieszczony w server_root/webapps/ROOT/WEB-INF/package/name.HelloWorld. Nie wszystkie serwery zezwalają automatycznie na dostęp do apletów przez użycie rodzajowego przedrostka /servlet/. Funkcja ta może zostać wyłączona ze względów bezpieczeństwa, aby zapewnić, że dostęp do apletów jest możliwy tylko przez określoną konfigurację URL-u, w czasie administrowania serwerem. W celu zapoznania się ze szczegółami wyłączania i załączania przedrostka /servlet/ należy zapoznać się z dokumentacją serwera, na którym pracujemy.

Przetwarzanie danych formularzowych

Aplet „HelloWorld” nie jest zbyt skomplikowany, przejdźmy więc do rzeczy bardziej zaawansowanych. Tym razem utworzymy aplet, który będzie pozdrawiał użytkownika jego imieniem (i nazwiskiem). Nie jest to rzecz specjalnie skomplikowana, potrzebny jest nam najpierw formularz HTML, który spyta użytkownika o jego imię i nazwisko. Następująca strona powinna być w tym celu wystarczająca:

<HTML>

<HEAD>

<TITLE>Introductions</TITLE>

</HEAD>

<BODY>

<FORM METHOD=GET ACTION="/servlet/Hello">

Pozwól że spytam, jak się nazywasz?

<INPUT TYPE=TEXT NAME="imię i nazwisko"><P>

<INPUT TYPE=SUBMIT>

</FORM>

</BODY>

</HTML>

Na rysunku 2.4 został ukazany sposób, w jaki strona ta zostanie wyświetlona na stronie użytkownika.

Rysunek 2.4. Formularz HTML

Formularz ten powinien znaleźć się w pliku HTML, w katalogu serwera document_root. Jest to miejsce, w którym serwer szuka plików statycznych. Dla serweru „Tomcat” katalog ten to server_root/webapps/ROOT. Dzięki umieszczeniu pliku w tym katalogu, może być on dostępny bezpośrednio pod adresem: http://server:8080/form.html.

Kiedy użytkownik przesyła ten formularz, jego imię (i nazwisko) jest przesyłane do apletu „Hello” ponieważ uprzednio zainstalowaliśmy atrybut ACTION celem wskazania ich apletowi. Formularz używa metody GET, więc jakiekolwiek dane są dodawane do URL-u zlecenia jako pasmo zapytań. Jeżeli np. użytkownik wprowadzi imię, nazwisko „Inigo Montoya”, URL zlecenia będzie wyglądał następująco: http://server:8080/servlet/Hello?name=Inigo+Montoya. Przerwa pomiędzy imieniem a nazwiskiem jest wyjątkowo kodowana przez przeglądarkę jako znak „+”, ponieważ URL nie może zawierać spacji.

Obiekt apletu: HttpServletRequest umożliwia dostęp do danych formularzowych w paśmie zapytań. Na przykładzie 2.2 została ukazana zmodyfikowana wersja naszego apletu „Hello”, która używa swojego obiektu zlecenia do odczytywania parametru name.

Przykład 2.2. Aplet, który „wie” kogo pozdrawia

import java.io.*;

import javax.servlet.*;

import javax.servlet.http.*;

public class Hello extends HttpServlet {

public void doGet (HttpServletRequest req, HttpServletResponse res)

throwsServletException, IOException {

res.setContentType ("text/html");

PrintWriter out = res.getWriter ( );

String name = req.getParameter ("imię i nazwisko");

out.println("<HTML>");

out.println("<HEAD><TITLE>Hello, " + name + "</TITLE><HEAD>");

out.println("<BODY">);

out.println ("HELLO, " + name);

out.println (</BODY></HTML>");

}

public String getServletInfo() {

return "aplet, który wie jak nazywa się osoba, do której + "mówi hallo";

}

}

Powyższy aplet jest niemal identyczny z apletem „HelloWorld”. Najważniejsza różnica jest taka, że teraz wywoływane jest reg.getParameter("name") w celu ustalenia imienia i nazwiska użytkownika oraz, fakt, że następnie to imię i nazwisko jest wyświetlane ,zamiast nieprzyjemnie bezosobowego (nie mówiąc już, że nadmiernie obszernego pojęciowo) „World”. Metoda getParameter() daje apletowi dostęp do parametrów w jego paśmie zapytań. Wartość zdekodowana parametru jest następnie odsyłana, lub jeżeli parametr nie był określony — null. Jeżeli parametr został przesłany lecz nie została podana jego wartość, tak jak w przypadku pustego pola formularzowego, getParameter() odsyła pusty wiersz. Aplet ten dołącza również metodę getServletInfo. Aplet może zignorować tę metodę w celu odesłania informacji opisowych o nim samym, takich jak np. cel jego działania, jego autor, wersja i (lub) prawa autorskie.

Jest to podobna sytuacja do apletu getAppletInfo(). Metoda jest używana zasadniczo w celu umieszczania wyjaśnień na administracyjnym programie serwisowym serwera WWW, dlatego nie będzie zamieszczana w następnych przykładach jako że wprowadza tylko niepotrzebne zamieszanie w procesie uczenia.

Wygląd apletu jest mniej więcej taki, jak na rysunku 2.5.

Rysunek 2.5. Aplet „Hello” używający danych formularzowych

Obsługa zleceń POST

Po omówieniu dwóch apletów, które wdrażają metodę doGet()możemy przejść do przerobienia naszego apletu „Hello” w taki sposób, aby również obsługiwał zlecenia POST. Naszym zadaniem jest doprowadzenie do tego, aby aplet zachowywał się tak samo jak przy metodzie POST, jak to miało miejsce przy GET, możemy to uzyskać wysyłając po prostu wszystkie zlecenia POST do metody doGet() za pomocą następującego kodu:

Public void do Post (HttpServletRequest reg, HttpServletResponse res)

throws ServletException, IOException {

doGet (reg, res);

}

Teraz już aplet „Hello” jest w stanie obsłużyć przedłożenia formularzy, które używają metody POST:

<FORM METHOD=POST ACTION="/servlet/Hello">

Ogólnie rzecz biorąc, najlepiej jest kiedy aplet wdraża albo metodę doGet() albo doPost().

Aplet wybierając jedną w wyżej wymienionych metod bierze pod uwagę jaki rodzaj zlecenia będzie musiał obsłużyć (tak, jak to zostało omówione wcześniej). Kody wprowadzane, potrzebne do wdrożenia obu metod są niemal takie same. Różnica polega na tym, że metoda doPost() ma dodatkowo zdolność przyjmowania dużych ilości danych wejściowych.

Zastanowimy się co by się stało, gdybyśmy połączyli się z apletem „Hello” złożywszy zlecenie POST, przed wdrożeniem doPost() — domyślne zachowanie apletu odziedziczone po HttpServlet dla obu metod doGet() i doPost(), to zawiadomienie klienta, iż żądany URL nie współpracuje z tą metodą.

Obsługa zleceń HEAD

Odrobina pomysłowości sprawia, że obsługa zleceń HEAD (przesyłanych przez klienta, który chce oglądać tylko nagłówki odpowiedzi) staje się dziecinnie prosta , zaraz wyjaśnimy na czym rzecz polega. W takiej sytuacji nie piszemy przede wszystkim metody doHead() (jakkolwiek aplet, który jest podklasą dla HttpServlet oraz wdraża metodę doGet() automatycznie współpracuje ze zleceniami HEAD).

A oto jak się to odbywa: metoda service() HttpServlet identyfikuje zlecenie HEAD i traktuje je odmiennie. Konstruuje mianowicie zmodyfikowany obiekt HttpServletResponse i następnie przekazuje go razem z niezmienionym zleceniem do metody doGet(). Ta ostatnia metoda postępuje w sposób standardowy, z tą różnicą tylko, że nagłówki, które ustala przesyła klientowi. Obiekt specjalnej odpowiedzi skutecznie tłumi wszystkie treści wychodzące.

Mimo, iż taka strategia jest wygodna, możliwe jest również usprawnienie procesu poprzez wykrywanie zleceń HEAD w metodzie doGet(), dzięki temu możliwa jest wcześniejsza odpowiedź (bez niepotrzebnych cyklów pisania danych wychodzących, których nikt nie będzie czytał). Na przykładzie 2.3 został ukazany sposób , w jaki za pomocą metody getMethod() zlecenia, można wdrożyć wspomnianą strategię w naszym serwerze „Hello”.

Przykład 2.3. Aplet „Hello” zmodyfikowany w sposób umożliwiający szybkie odpowiadanie na zlecenia HEAD

import java.io.*;

import javax.servlet.*;

import javax.servlet.http.*;

public class Hello extends HttpServlet {

public void doGet (HttpServletRequest req, HttpServletResponse res)

throws ServletException, IOException {

// Wstaw nagłówek Typ Zawartości

res.setContentType ("text/html");

// Odeślij bezzwłocznie jeżeli to jest HEAD

if. (req.getMethod ( ).equals ("HEAD")) return;

// W przeciwnym razie postępuj

PrintWriter out = res.getWriter ( );

String name = req.getParameter ("imię i nazwisko");

out.println("<HTML>");

out.println("<HEAD><TITLE>Hello, " + name + "</TITLE><HEAD>");

out.println("<BODY">);

out.println ("HELLO, " + name);

out.println (</BODY></HTML>");

}

}

Zwróćmy uwagę, iż nawet wtedy, kiedy obsługujemy zlecenia HEAD, wstawiamy nagłówek Content-Type. Nagłówki takie są odsyłane do klienta. Niektóre wartości nagłówków, takie jak np. Content-Lenght mogą nie być dostępne do czasu wygenerowania całej odpowiedzi. Skuteczność takiego skrótu może być ograniczona , należy więc być ostrożnym jeżeli chce się precyzyjne określać wartości nagłówków.

Jest rzeczą ważną ażeby zakończyć obsługę zlecenia instrukcją return. Nie należy wywoływać System.exit(), ponieważ grozi to wyjściem z serwera.

Aplikacje WWW

Aplikacje WWW (czasem w skrócie określana web app) to zbiór apletów, stron systemów Javy (JSPs), dokumentów HTML, obrazów, szablonów oraz innych zasobów sieci WWW, które zostały skonfigurowane w taki sposób , aby mogły być łatwo zainstalowane na każdym serwerze WWW udostępniającym aplety. Dzięki standaryzacji umiejscowienia plików w aplikacji WWW oraz standaryzacji formatu konfiguracji pliku, aplikacja WWW może być przesyłana z jednego serwera na drugi bez potrzeby dodatkowego zarządzania serwerem. Czasy, kiedy do zainstalowania komponentów sieciowych innej firmy potrzebne było mnóstwo stronic zawierających szczegółowe instrukcje, odmienne dla każdego typu serwera należą już do przeszłości.

Wszystkie pliki w server_root/webapps/ROOT należą do jednej aplikacji WWW (aplikacji głównej). Pliki te, celem uproszczenia instalacji, mogą zostać zebrane w jeden plik archiwalny i zainstalowane na innym serwerze — poprzez samo umieszczenie tego pliku w określonym katalogu. Pliki te mają rozszerzenie .war (skrót od: web application archive). Pliki WAR to właściwie pliki JAR (utworzone przy pomocy programu narzędziowego jar) zapisane w zastępczym rozszerzeniu. Zastosowanie formatu JAR pozwala na przechowywanie plików WAR w formie skompresowanej oraz opatrywanie ich zawartości podpisem elektronicznym. Zamiast rozszerzenia .war wybrano rozszerzenie .jar, żeby zasygnalizować użytkownikom oraz narzędziom, których używają, iż pliki te należy traktować inaczej.

Struktura organizacji plików w aplikacji WWW została ściśle określona. Na przykładzie 2.4 został ukazany listing plików.

Przykład 2.4. Struktura organizacji plików w aplikacji WWW

index.html

feedback.jsp

images/banner.gif

images/jumping.gif

WEB-INF/web.xml

WEB-INF/lib/bhawk4j.jar

WEB-INF/classes/Myservlet.class

WEB-INF/classes/com/mycorp/frontend/CorpServlet.class

WEB-INF/classes/com/mycorp/frontend/SupportClass.class

Taka hierarchia może być utrzymana jako oddzielne pliki w katalogu jakiegoś serwera lub też pliki te mogą zostać zapisane jako plik WAR. Przy Instalowaniu ta aplikacja WWW może zostać przekształcona z jakimkolwiek przedrostkiem pliku URI na serwerze. Aplikacja WWW obsługuje wtedy wszystkie zlecenia mające taki przedrostek. Jeżeli na przykład poprzednia struktura plików została utworzona pod przedrostkiem /demo, serwer użyje tej aplikacji WWW w celu obsłużenia wszystkich zleceń zaczynających się od /demo. Odpowiedzią dla zlecenia na demo/index/.html będzie plik index.html z aplikacji WWW. Zlecenie na /demo/feedback.jsp lub /demo/images/banner.gif zostało by także obsłużone z aplikacji WWW.

Katalog WEB-INF

Katalog WEB-INF jest wyjątkowy — pliki nie są przesyłane bezpośrednio do klienta, zamiast tego zawierają one klasy Java oraz informacje o konfiguracji dla aplikacji WWW. Katalog ten zachowuje się jak katalog META-INF pliku JAR: zawiera meta-informacje o treściach archiwalnych.

Katalog WEB-INF/classes zawiera pliki klas dla apletów aplikacji WWW oraz klasy wspomagające. WEB-INF/lib zawiera klasy przechowywane jako pliki JAR. Dla ułatwienia programy ładujace klasy serwera maja automatyczny wgląd do WEB-INF/classes oraz do WEB-INF/lib podczas ładowania klas, wiec nie trzeba wykonywać dodatkowych czynności przy instalowaniu tej aplikacji.

Aplety w tej aplikacji WWW mogą zostać wywołane przy użyciu URI , takich jak np.

/demo/servlet/Myservlet oraz /demo/ servlet/com.mycorp.frontend.CorpServlet. Zwróćmy uwagę , iż każde zlecenie na tą aplikacje zaczyna sie od /demo nawet zlecenia na aplety. W przypadku serwera „Tomcat” server_root/webapps/ROOT jest kontekstem domyślnym przekształconym na główną ścieżkę dostępu nazwy pliku. Oznacza to, iż dostęp do apletów znajdujących się w server_root/webapps/ROOT/WEB-INF/classes możliwy jest tak, jak pokazywaliśmy wcześniej, przy użyciu przedrostka /servlet/HelloWorld. W serwerze „Tomcat” domyślne odwzorowanie kontekstowe może zostać zmienione, a nowe odwzorowania mogą zostać dodane przy użyciu pliku konfiguracyjnego działającego na wszystkich serwerach o nazwie serwer_root/conf/server.xml. Na innych serwerach konfiguracja odwzorowania przebiega w inny sposób (szczegóły można znaleźć w dokumentacji serwera).

Plik web.xml, znajdujący się w katalogu WEB-INF zwany jest deskryptorem wdrożenia. Zawiera on informacje o konfiguracji aplikacji WWW, w której się znajduje. Jest to plik XML ze standaryzowanym DTD. DTD zawiera ponad 50 znaczników, pozwalając tym samym na pełną kontrolę nad aplikacją WWW. Plik deskryptora wdrożenia kontroluje rejestrację apletu, odwzorowanie URL, przyjmuje pliki i typy MIME jak również funkcje zaawansowane, takie jak regulacja poziomu zabezpieczeń strony oraz wpływa na zachowanie się apletu w środowisku rozproszonym. Zawartość tego pliku będzie omówiona szerzej w następnych rozdziałach. Szczegółowo opisane DTD można znaleźć w dodatku C „Opis deskryptora wdrożenia DTD”.

Struktura pliku web.xml nie jest rzeczą istotną na ten moment. Ważny jest fakt, iż plik deskryptora wdrożenia pozwala na wyszczególnienie informacji konfiguracyjnych w sposób niezależny od serwera, upraszczając tym samym znacznie proces wdrażania. Deskryptory wdrożenia nie tylko umożliwiają przenoszenie prostych apletów lecz również pozwalają ma międzyserwerowy transfer podsekcji naszych stron.

Popyt na pliki WAR będzie prawdopodobnie rozwijał się z biegiem czasu. Staną się one prawdopodobnie integralna częścią sieci. Prawdopodobnie będzie je można również ładować i instalować i będą od razu gotowe do pracy — bez względu na to, jaki system operacyjny jest używany przez nas lub przez nasz serwer WWW.

!!!!!!!!!!początek ramki

--> XML [Author:G] i DTD

XML to angielski skrót (Extensible Markup Language)^a , który można przetłumaczyć jako rozszerzalny język oznaczania znaczników, oznaczający rozszerzenie HTML-a. Jest to uniwersalna składnia (syntaktyka) tworzenia struktury danych, stworzona przez Konsorcjum „World Wide Web Consortium” (W3C), mająca swój początek w 1996 roku. Od czasu swojej standaryzacji w 1998 roku podbija sieć w zawrotnym tempie.

Cechą wspólna dla XML i HTML-u jest to ,że zarówno XML, jak i HTML określają treść i „mark it up” używając znaczników zawartych w nawiasach ostrych jak np. <title> i </title>. Jednakże XML spełnia nieco inną rolę niż HTML — załączniki w dokumentach XML nie określają sposobu wyświetlania tekstu, lecz raczej wyjaśniają jego znaczenie. XML jest to „rozszerzalny” język, oznaczania znaczników, ponieważ nowe znaczniki mogą być tworzone ze swoim własnym znaczeniem, właściwym dla tworzonego dokumentu. XML działa najlepiej w formacie pliku jednorodnego, ponieważ jest to standardowa, dobrze opisana i niezależna od platformy technika stworzona dla danych hierarchicznych, istnieje także wiele programów narzędziowych wspomagających odczytywanie, tworzenie oraz operowanie plikami XML.

Zasady pisania w XML-u są bardziej restrykcyjne niż w przypadku HTML-u. Przede wszystkim znaczniki XML reagują na wielkość liter i tak inna będzie reakcja na napis <servlet>, a inna na <SERVLET>. Drugą ważną sprawą przy pisaniu w XML-u jest to, że rozpoczynając danym oznaczeniem musimy nim także zakończyć. Tak np. jeżeli rozpoczniemy znacznikiem rozpoczynającym <servlet> to musimy zakończyć znacznikiem końcowym </servlet>. Dla ułatwienia pusty znacznik składniowy <servlet> może zostać użyty jako substytut oznaczenia jednoczesnego rozpoczęcia i zakończenia, pary znaczników <servlet></servlet>. Trzecia zasada jest taka, że elementy zagnieżdżone nie mogą się na siebie nakładać. Tak więc właściwym będzie układ <outside><inside>data</inside></outside>, układem niewłaściwym natomiast będzie <outside><inside>data</outside></inside>. Po czwarte, wszystkie wartości atrybutów muszą być „wzięte” w cudzysłów (pojedynczy lub podwójny). Tak więc właściwy będzie zapis <servlet id="O"/> a niewłaściwy <servlet id=O/>. Dokumenty (zwane well-formed) spełniające powyższe zasady, będą całkowicie przetwarzane przez automatyczne programy narzędziowe.

Poza tymi zasadami, istnieją także sposoby szczegółowego określania struktury znaczników w pliku XML. Specyfikacja tego typu jest określana jako Dokumentacja typu dokumentu (DTD). DTD szczegółowo precyzuje jakie znaczniki mogą znaleźć się w pliku zgodności XML, jaki rodzaj danych mają zawierać te znaczniki oraz to gdzie w hierarchii mają (lub muszą) znajdować się te znaczniki. Każdy plik XML może być zadeklarowany do pewnego DTD. Pliki które całkowicie dostosowują się do DTD, do których są zadeklarowane nazywamy valid. XML jest używany w apletach jako format pamięci przy konfiguracji plików. XML może być również używany przez aplety przy tworzeniu treści , jak to zostało opisane w rozdziale 17 „XMLC” Więcej informacji o XML-u można znaleźć na stronie http://www.w3.org/XML/ oraz w książce --> Bretta McLaughlin'a „Java and XML” (wydawnictwo O'Relly)[Author:PG] .

!!!!!!!!!!!!!!!!koniec ramki

Deskryptory wdrożenia z prostym sposobem obsługi wielu użytkowników na tym samym serwerze są również oferowane przez firmy zajmujące się obsługują sieci WWW. Użytkownicy mogą uzyskać kontrole nad swoimi domenami — mogą oni nadzorować rejestrację apletu, odwzorowanie URL-u, rodzaj MIME oraz poziom zabezpieczenia strony — bez potrzeby ogólnego dostępu do serwera.

Deskryptor wdrożenia

Prosty deskryptor wdrożenia został pokazany na przykładzie 2. Żeby sprawić, by plik ten opisywał domyślną aplikacją WWW serwera „Tomcat” musimy go umieścić w server_root/webapps/ROOT/WEB-INF/web.xml.

Przykład 2.5.

Prosty deskryptor wdrożenia

<?xml wersja="1.0" kodowannie="ISO-8859-1"?>

<!DOCTYPE web-app

PUBLIC "-//Sun Microsystems, Inc.// DTD Web Application 2.2 // EN"

"http: // java.sun.com/j2ee/dtds/web-app_2_2.dtd">

<web-app>

<servlet>

<servlet-name>

hi

</servlet-name>

<servlet-class>

HelloWorld

</servlet-class>

</servlet>

</web-app>

Pierwszy wiersz oznacza, iż jest to plik XML 1.0 zawierający znaki ze standardu ISO-8859-1 (Latin-1) charset. Drugi wiersz określa DTD dla pliku, pozwalając tym samym programowi bibliotecznemu, czytającemu plik na jego weryfikację (czy jest valid) oraz sprawdzenie czy odpowiada zasadom DTD. Wszystkie pliki deskryptora wdrożenia zaczynają się opisanymi dwoma wierszami lub bardzo podobnymi do nich.

Pozostała część tekstu — pomiędzy <web-app> a </web-app> dostarcza serwerowi informacji o tej aplikacji WWW. Ten prosty przykład rejestruje nasz aplet „Hello World” przed nazwą hi (otaczający biały obszar jest wycinany). Zarejestrowana nazwa jest tu umieszczana pomiędzy znacznikami <servlet-class>. Znacznik <servlet> „spina” znaczniki <servlet-name> oraz <servlet-class>. Składnia deskryptora wdrożenia XML wydaje się być lepiej zoptymalizowana dla odczytu automatycznego, raczej niż dla bezpośredniego (przez człowieka).

Dlatego też większość producentów oferuje środki graficzne pomocne w procesie tworzenia web.xml. Na rynku dostępnych jest również wiele edytorów XML, które można wykorzystać przy tworzeniu XML-u.

!!!!!!!!!!!!!!!!!!!!początek ramki

Uwaga na kolejność znaczników

Nie wszyscy uświadamiają sobie fakt, iż znaczniki w web.xml są uwarunkowane co do kolejności. Dla przykładu, żeby wszystko działało poprawnie znacznik <servlet-name> musi znajdować się przed znacznikiem <servlet-class>. Taka jest ich kolejność, w której zostały zdeklarowane w DTD. Analizatory sprawdzające poprawność składni wprowadzają taką kolejność oraz deklarują dokument jako nieprawidłowy (invalid) jeżeli kolejność nie jest zachowana. Niektóre serwery, nawet te bez analizatorów poprawności składni, mogą być po prostu przygotowane na przyjęcie takiej kolejności, mogą więc być zdezorientowane w przypadku otrzymania innej. Dla pewności należy upewnić się, ze wszystkie znaczniki <web-app> zostały uporządkowane we właściwej kolejności. Niektóre znaczniki mogą, lecz nie muszą być obecne, lecz te, które zostały przez nas zapisane muszą być we właściwym porządku. Na szczęście istnieją narzędzia, które upraszczają to zadanie (więcej informacji znajduje się w dodatku C — pod DTD).

!!!!!!!!!!koniec ramki

Po rejestracji, oraz po ponownym uruchomieniu serwera możemy wejść do apletu „Hello World” pod URL-em: http://server:8080/servlet/hi. Może zastanawiać fakt dlaczego ktoś miałby zadawać sobie trud rejestracji apletu pod specjalna nazwą. Odpowiedź jest taka, że procedura ta pozwala na „zapamiętanie” przez serwer szczegółów związanych z apletem i traktować go w szczególny sposób. Jednym z przykładów takiego traktowania jest możliwość ustalenia wzorców URL, które wywołują zarejestrowany aplet. Klient może postrzegać URL będący przedmiotem zlecenia , tak jak każdy inny, jednakże serwer jest w stanie stwierdzić , że zlecenie jest zgodne z odwzorowaniem modelu (wzoru) i dzięki temu może być obsłużone przez odpowiedni aplet. Możemy dla przykładu sprawić, że http://server:8080/hello.html wywoła aplet „HelloWorld”. Użycie odwzorowań apletu w ten sposób, pomaga ukryć , że strona używa apletów. Użycie to również pozwala apletowi na płynne zastąpienie istniejącej pod jakimkolwiek URL-em adresem strony, tak więc wszystkie zakładki oraz łączniki (linki) do strony nadal będą działać. Wzory URL konfigurowane są przy użyciu deskryptora wdrożenia, tak jak zostało to zaprezentowane na przykładzie 2.6.

Przykład 2.6.

Dołączanie odwzorowania apletu

<?xml version="1.0" kodowanie="ISO-8859-1"?>

<!DOCTYPE web-app

PUBLIC "-//Sun Microsystems, Inc.// DTD Web Application 2.2 // EN"

"http: // java.sun.com/j2ee/dtds/web-app_2_2.dtd">

<web-app>

<servlet>

<servlet-name>

hi

</servlet-name>

<servlet-class>

HelloWorld

</servlet-class>

</servlet>

<servlet -mapping>

<servlet -name>

hi

<servlet -name>

<url-pattern>

/hello.html

</url-pattern>

</servlet-mapping>

</web-app>

Powyższy deskryptor wdrożenia dodaje zapis <servlet-mapping> informując tym samym serwer, że aplet hi powinien obsłużyć wszystkie URL-e zgodne ze wzorem dostępu do ścieżki głównej /hello.html. Jeżeli aplikacja WWW zostanie przekształcona do głównej ścieżki „/” pozwoli to apletowi „Hello World” obsłużyć zlecenie na http://server:8080/hello.html. Jeżeli zamiast powyższego aplikacja WWW zostanie przekształcona do ścieżki dostępu przedrostka /greeting: aplet „Hello” obsłuży zlecenia złożone na http://server:8080/greeting/hello.html.

Różne zasady odwzorowania URL-u mogą zostać wyszczególnione w deskryptorze wdrożenia. Istnieją cztery rodzaje (style) odwzorowania, wyszukiwane w następującej kolejności:

• Odwzorowania jawne, takie jak /hello.html lub /images/chart.gif, które nie zawierają symboli wieloznacznych. Ten styl odwzorowania jest pomocny w zastępowaniu istniejącej strony.

• Odwzorowania ścieżki dostępu przedrostka takie jak /lite/*, /dbfile/* lub /catalog/item/* Odwzorowania te zaczynają się od a /, a kończą na a/* i obsługują wszystkie zlecenia rozpoczynające się takimi przedrostkami (nie licząc kontekstu ścieżki dostępu). Ten styl odwzorowania pozwala apletowi na kształtowanie całej hierarchii sieciowej. Dla przykładu, aplet obsługujący /dbfile/* może serwować pliki z bazy danych, podczas gdy aplet obsługujący /lite/* może przesyłać pliki z systemu plików automatycznie skompresowanych.

• Odwzorowania rozszerzenia takie jak *.wm lub .jsp. Takie odwzorowania zaczynają się od a* i obsługują wszystkie zlecenia kończące się tym przedrostkiem. To odwzorowanie pozwala apletowi na operowanie na wszystkich plikach określonego rozszerzenia. Dla przykładu aplet może zostać przypisany do obsługi plików kończących się na *.jsp celem obsługi stron JavaServer (jest to de facto odwzorowanie niejawne będące domeną specyfikacji apletu).

• Odwzorowanie domyślne /. Odwzorowanie to określa serwer domyślny dla aplikacji WWW — jeżeli inne nie będą pasowały. Jest ono identyczne z ograniczonym odwzorowaniem ścieżki dostępu przedrostka (/*), wyjątek stanowi fakt iż odwzorowanie to jest brane pod uwagę po odwzorowaniach rozszerzenia. Odwzorowanie to daje kontrolę nad tym, w jaki sposób są wysyłane są podstawowe pliki — znacząca możliwość, która jednak powinna być wykorzystywana z rozwagą. W sytuacji kolizji odwzorowań dokładne (ścisłe) dopasowania mają pierwszeństwo przed dopasowaniami przedrostków, a dopasowanie ścieżki dostępu przedrostka przed dopasowaniami rozszerzenia. Odwzorowanie domyślne jest wywoływane tylko wtedy, kiedy nie występują żadne inne dopasowania. Dopasowania o dłuższym ciągu znaków w grupie traktowane są priorytetowo przed dopasowaniami o krótszym ciągu.

Deskryptor „snippet” zaprezentowany na przykładzie 2.7 prezentuje różne odwzorowania, które mogą być użyte do wchodzenia do apletu „Hello World”.

Przykład 2.7. Sposoby powiedzenia „Hello”

<!--... -->

<servlet-mapping>

<servlet-name>

hi

</servlet-name>

<url-pattern>

/hello.html

</url-pattern>

</servlet-mapping>

<servlet-mapping>

<servlet-name>

hi

</servlet-name>

<url-pattern>

*.hello

</url-pattern>

</servlet-mapping>

<servlet-mapping>

<servlet-name>

hi

</servlet-name>

<url-pattern>

/hello/*

<url-pattern>

<servlet-mapping>

<!--... -->

Aplet „Hello World” może być wywołany poprzez użycie jednego z odwzorowań znajdujących sie na poniższej liście:

/servlet/HelloWorld

/servlet/hi

/hello.html

/well.hello

/fancy/meeting/you/here.hello

/hello/to/you

Bardziej praktyczne odwzorowania zostaną zaprezentowane w dalszych rozdziałach niniejszej książki.

Przejdźmy dalej

Duża ilość informacji o apletach, aplikacjach WWW oraz plikach konfiguracyjnych XML zwartych w niniejszym wprowadzeniu powinna być wystarczająca do uzyskania pojęcia jak tworzyć proste aplety, instalować je na serwerach oraz informować serwery o ścieżkach, dla których chcemy wykonywać wspomniane aplety. Możliwości apletów znacznie przekraczają wyświetlanie „Hello World” czy pozdrawianie użytkowników ich imionami i nazwiskami — właśnie o tym będzie traktować dalsza część książki.

*Pierwszy przykład zarejestrowanego programu „Hello World” pojawił się w „A Tutorial Introduction to the Language B”, napisanym przez Braiana Kernighana w 1973. Dla tych z czytelników, zbyt młodych, by pamiętać, język B był prekursorem języka C. Więcej informacji o języku programowania B oraz link do tej książki można znaleźć na stronie: http://cm.bell-labs.com/who/dmr/bintro.html.

^a XML miał być uprzednio nazwany MAGMA. Więcej na stronie na stronie http://www.xml.com/axml/notes/TheCorrectTitle.html.

2 Część I ♦ Podstawy obsługi systemu WhizBang (Nagłówek strony)

2 C:\0-praca\Java Servlet - programowanie. Wyd. 2\r02-04.doc

Do red.prow.: Może coś naszego?

Tytuł Dodatku D

To ma być w formie rameczki

Do red.prow.: Może coś naszego?

---