Professional Documents
Culture Documents
Cel laboaratorium:
Zaznajomienie si z rodowiskiem potrzebnym do tworzenia Aplikacji webowych tworzonych w
technologii JavaEE. Poznanie i konfiguracja wybranego serwera aplikacyjnego. Stworzenie i
uruchomienie prostej aplikacji webowej opartej na koncepcji servletw.
Wstp.
Java EE (nazywana dawniej J2EE) wykorzystuje standardowy zestaw technologii do tworzenia aplikacji
uruchamianych po stronie serwera. Technologia Javy EE zawiera servlety, Java Server Pages (JSP),
Java Server Faces (JSF), Enterprise JavaBeans (EJB), Context Dependency Injection (CDI), Java essaging
Service (JMS), Java Persistence API (JPA), Java API for XML Web Services (JAX-WS) i Java API for ESTful
Web Services (JAX-RS), a take kilka innych.
Istnieje kilka serwerw aplikacji umoliwiajcych programistom uruchamianie aplikacji zgodnych z
Jav EE, jedne s komercyjne, inne ze rdami otwartymi. JBoss AS to jedno z wiodcych rozwiza
typu open source wykorzystywanych przez programistw. Cho trudno to dokadnie zmierzy, jest
wielce prawdopodobne, e stanowi on najczciej wykorzystywany serwer aplikacyjny na rynku.
Inne popularne serwery apliakcyjne to Apache Tomcat oraz Glassfish.
wiczenia
Pierwszym krokiem przed przystpieniem do waciwej nauki serwera aplikacji jest instalacja na
komputerze wszystkich elementw niezbdnych do uruchomienia tego serwera.
Serwer aplikacji wymaga tylko rodowiska maszyny wirtualnej Javy.
W kwestii wymaga sprztowych warto wiedzie, e dystrybucja serwera wymaga jako minimum
okoo 75 MB przestrzeni na dysku twardym i alokuje od 64 MB (minimum) do 512 MB pamici RAM
w przypadku serwera niezalenego.
Przygotowanie rodowiska wymaga bdzie realizacji pewnych krokw. Oto one:
Instalacja Java Development Kit pozwalajcego na uruchomienie JBoss AS 7.
Instalacja JBoss AS 7.1.1.
Instalacja rodowiska programistycznego Eclipse.
Instalacja narzdzia Maven.
Jeli masz wasny laptop kolejno zainstaluj wymagane elementy ( moliwe zamiana serwera JBoss
na inny serwer Aplikacyjny podobnie jak i rodowiska IDE).
Instalacja JBoss AS 7 - Serwer aplikacji JBoss mona pobra bezpatnie z witryny spoecznoci pod
adresem http://www.jboss.org/jbossas/downloads/.
Wskazane polecenie uruchamia niezalen instancj serwera JBoss, ktra jest rwnowana
uruchomieniu serwera aplikacji poleceniem run.bat (lub run.sh) we wczeniejszej wersji JBoss.
Jeli konieczne jest dostosowanie waciwoci pocztkowych serwera aplikacji, trzeba otworzy plik
standalone.conf (lub plik standalone.conf.bat w przypadku systemu Windows) i znale fragment
odpowiedzialny za wymagania pamiciowe. Oto odpowiedni fragment dla systemu Linux.
if [ "x$JAVA_OPTS" = "x" ]; then
JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.
warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 - Dsun.rmi.dgc.
server.gcInterval=3600000"
fi
Domylnie serwer uywa minimalnie 64 MB pamici operacyjnej na stos i maksymalnie 512 MB RAM.
To odpowiednie wartoci na pocztek. Jeli jednak na serwerze maj by uruchamiane bardziej
rozbudowane aplikacje Javy EE, najprawdopodobniej potrzeba bdzie minimum 1 GB pamici, a
czasem nawet 2 GB.
Warto sprawdzi, czy uruchomiony serwer jest dostpny przez interfejs sieciowy, wskazujc w
przegldarce oglnie znany domylny adres strony pocztkowej serwera aplikacji:
http://localhost:8080.
Jeli wszystko jest w porzdku powinien pokaza si w oknie przegldarki nastpujcy ekran:
Po walidacji wprowadzonych danych pojawi si proba o ich potwierdzenie. Naley wpisa tekst yes;
plik waciwoci zosta uaktualniony.
Jeeli korzysta si z wydania nowszego ni 7.1.1, pojawi si dodatkowe pytanie (Is this new user going
to be used for one AS process to connect to another AS process?), ktre dotyczy dodania
podrzdnych kontrolerw hostw wykorzystujcych gwny kontroler domeny. Krok ten wymaga
dodania tajnego klucza do konfiguracji hostw podrzdnych, by mogy si waciwie uwierzytelni w
momencie pobierania danych z gwnego kontrolera domeny. (Wicej informacji na temat
konfiguracji
domeny
znale
mona
na
stronie
dostpnej
pod
adresem
https://docs.jboss.org/author/display/AS71/Admin+Guide#AdminGuide-ManagedDomain).
Uruchomienie konsoli webowej
Po dodaniu przynajmniej jednego uytkownika mona przystpi do uruchomienia konsoli webowej
dostpnej pod domylnym adresem http://<host>:9990/console.
Pojawi si proba o podanie nazwy uytkownika oraz hasa. Wpisujemy w polach Nazwa uytkownika
i Haso dane uyte przy tworzeniu nowego uytkownika.
Teraz naley wpisa nazw aplikacji i wczy opcj Use default location, jeli projekt ma powsta w
tej samej lokalizacji, co przestrze robocza Eclipse. Jeli nowy serwer JBoss AS 7.1 zosta poprawnie
skonfigurowany w IDE Eclipse, na licie rozwijanej Target Runtime powinna pojawi si opcja JBoss
7.1 Runtime. Jej wybr spowoduje automatycznie uycie Default Configuration for JBoss 7.1 Runtime
na licie rozwijanej Configuration.
Jako Dynamic web module version wybieramy 3.0, co umoliwi atwiejsze tworzenie kodu dziki
zastosowaniu specyfikacji serwletw w wersji 3.0. Pole wyboru w grupie EAR membership
ozostawiamy niezaznaczone.
Klikamy Finish, by kontynuowa.
Dodajemy do projektu kwintesencj serwletu, czyli bardzo prost klas odpowiedzialn jedynie za
wywietlenie komunikatu typu Witaj, wiecie. Z menu File wybieramy New/Servlet. Wpisujemy
sensown nazw klasy i pakietu.
Kreator utworzy bardzo prosty szkielet servletu, ktry wystarczy zamieni na poniszy, minimalny
fragment kodu.
@WebServlet("/test")
public class TestServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
Zaznaczamy projekt i klikamy Add, aby doda go do listy skonfigurowanych zasobw na serwerze.
Przy zaoeniu, e serwer JBoss AS zosta uruchomiony z poziomu Eclipse, zasb zostanie
automatycznie wdroony, jeli wczona bdzie opcja If server is started, publish changes
immediately.
Jeli jednak serwer zosta uruchomiony poza Eclipse, pen publikacj mona wykona poprzez
kliknicie zasobu prawym przyciskiem myszy i wybranie z menu kontekstowego opcji Full Publish.
wiczenie 6. Zapoznaj si z opisem koncepcji serveta i cyklu ycia aplikacji webowej w JavaEE
przedstawionym poniej.
Cz teoretyczna.
Servlety to klasy, ktrych celem jest przetwarzanie da HTTP i generowanie zawartoci ktra
bdzie odesana w odpowiedzi na te dania. Innymi sowy, servlety su do implementacji
dynamicznych aplikacji WWW.
Z zaoenia servlety mog obsugiwa take protokoy inne ni HTTP, jednak w praktyce ich uycie
ogranicza si niemal wycznie do implementacji aplikacji WWW opartych na HTTP. Moemy zatem
myle o servletach jak o narzdziu sucym tylko i wycznie do tego wanie celu.
Przechodzc do konkretw - servlety to klasy, ktre implementuj interfejs javax.servlet.Servlet.
Moemy zaimplementowa servlet jako klas implementujc ten interfejs, jednak atwiej bdzie
nam zaimplementowa klas dziedziczc z klasy javax.servlet.http.HttpServlet (ktra to klasa
implementuje interfejs Servlet). Tak wanie w praktyce robi si najczciej. Przykad poniej:
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.io.PrintWriter;
public class HelloWorldServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
protected void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("<html><head><title>My Servlet</title></head><body>");
out.println("Hello World!");
out.println("<body></html>");
out.close();
}
}
Kade danie HTTP ma swj typ, definiujcy akcj ktr serwer powinien wykona w odpowiedzi.
Podstawowe typy da to dania GET i POST. danie GET oznacza, e klient wysyajcy danie do
serwera chce pobra zasb wskazywany przez URI przekazany wraz z tym daniem. danie POST
oznacza, e klient wysya do serwera, a konkretnie do zasobu wskazanego przez URI doczony do
dania, pewn porcj danych i zleca przetworzenie tych danych. W kadym daniu przesyane s
dodatkowo (opcjonalnie) parametry, nagwki, oraz ciasteczka. Kady taki element dania moemy
pobra w kodzie Servletu i wykorzysta zgodnie ze swoj niczym nie skrpowan wol.
Implementujc klas servletu implementujemy de facto metody obsugujce dania HTTP. Aby
zaimplementowa obsug metody HTTP GET musimy zaimplementowa metod doGet(). Aby
zaimplementowa obsug metody HTTP POST musimy zaimplementowa metod doPost(). W
powyszym przykadzie zaimplementowalimy jedynie metod doGet(), co oznacza e servlet ten
obsuguje tylko i wycznie dania HTTP typu GET.
Metody doGet() i doPost() przyjmuj dwa parametry wywoania obiekty reprezentujce danie
i odpowied HTTP. Obiekty te s tworzone i przekazywane do implementowanego przez nas servletu
przez serwer aplikacji.
Parametr reprezentujcy danie HTTP to obiekt typu javax.servlet.http.HttpServletRequest. Obiekt
reprezentujcy odpowied to obiekt typu javax.servlet.http.HttpServletResponse. Z instancji
reprezentujcej danie odczytujemy szczegy dania (parametry, ciasteczka, nagwki itd.) a do
bufora zwizanego z instancj reprezentujc odpowied zapisujemy to, co ma by odesane do
klienta, czyli elementy strony WWW (np. HTML). W jaki sposb zapisujemy t odpowied widzimy na
powyszym przykadzie.
danie HTTP, zarwno typu GET jak i POST, okrela przede wszystkim URL zasobu do ktrego
wysyamy danie, ale moe dodatkowo zawiera pewn liczb parametrw. Wysyajc danie GET
klient ma moliwo przekazania parametrw poprzez doklejenie ich w odpowiedni sposb do URL.
W przypadku dania POST parametry przekazywane s w treci waciwej dania (ktrej nie
widzimy tworzy j za nas przegldarka WWW).
Oglna posta URL dla dania GET jest nastpujca: http://{domena}:{port}/{zasb}?{parametry}
Zarwno {port} jak i {zasb} s opcjonalne. Opcjonalne s take {parametry}, ale jeli chcemy je
przekaza wraz z daniem, to doklejamy je do koca URL po znaku zapytania.
Skadnia definicji pojedynczego parametru jest nastpujca: {nazwa}={warto}
Element {nazwa} to nazwa parametru a {warto} to jego warto. Kolejne definicje parametrw
oddzielamy od siebie znakiem &. Przykadowo, aby przekaza 3 parametry napisalibymy:
{nazwa}={warto}&{nazwa}={warto}&{nazwa}={warto}
dania typu POST su do wysyania formularzy, a parametry takich da to nic innego jak
wartoci wpisane w pola formularza. Przykadowy formularz poniej:
<form method="POST" action="http://test.pl/kalkulator">
x: <input type="text" name="paramX">
y: <input type="text" name="paramY">
<input type="submit" value="Dodaj">
</form>
Wywietlajc powyszy formularz w ramach strony HTML przegldarka wywietli dwa pola tekstowe
oraz przycisk ktrego kliknicie spowoduje wysanie dania POST. danie to bdzie zawierao dwa
parametry: parametr o nazwie paramX oraz paramY. Wartoci tych parametrw bd takie, jakie
wpiszemy w pola formularza.
Niezalenie od tego czy parametry przekazano w jeden czy drugi sposb, wraz z daniem GET czy
POST, odczytujemy je w kodzie servletu w ten sam sposb, tzn. za pomoc metody String
getParameter(String name) obiektu reprezentujcego danie.
Parametry s zawsze typu String, tak wic aby np. zaimplementowa servlet sumujcy dwie liczby
przekazane za pomoc formularza jako parametry dania musielibymy sparsowa je, tak aby
otrzyma zmienne typu int. W tym celu moemy posuy si metod statyczn int parseInt(String) z
klasy Integer. Poniej przykadowa implementacja takiego servletu:
Typowa aplikacja WWW skada si z wielu rnego rodzaju komponentw: plikw konfiguracyjnych,
plikw zasobw statycznych (np. HTML, JPG, CSS), plikw JSP, katalogw i oczywicie plikw
zawierajcych skompilowane klasy, w tym servlety.
Element oznaczony jako {katalog gwny} to katalog grupujcy wszystkie elementy naszej aplikacji.
Jego nazwa moe by dowolna, jednak domylnie nazwa ta czsto uywana jest przez serwer aplikacji
do okrelenia adresu URL pod jakim aplikacja ta jest serwowana.
W takim wypadku adresem URL naszej aplikacji bdzie: http://{adres serwera}/{katalog gwny}
Jeli np. katalog gwny naszej aplikacji nazwiemy myApp i aplikacj zainstalujemy na serwerze
aplikacji dostpnym pod adresem http://test.pl:8080, to aplikacja bdzie dostpna pod
adresem http://test.pl:8080/myApp.
Bardzo wanym katalogiem obecnym w kadej aplikacji jest katalog o nazwie WEB-INF, ktry musi
nazywa si dokadnie tak i musi by umieszczony bezporednio w katalogu gwnym.
Katalog WEB-INF ma t wasno, e wszystkie umieszczone w nim pliki i katalogi s chronione przed
bezporednim dostpem, tzn. nie jest moliwe pobranie adnego z umieszczonych w nim plikw przy
pomocy dania HTTP. Dla odmiany, wszystkie pliki umieszczone poza tym katalogiem serwer
aplikacji zwrci w odpowiedzi na danie typu GET, jeli do adresu URL aplikacji dodamy poprawn
ciek dostpu do tego pliku (wzgldem katalogu gwnego aplikacji).
Np. jeli w katalogu gwnym utworzymy katalog o nazwie html i w nim plik o nazwie strona.html, to
bdziemy mogli pobra ten plik (i wywietli w przegldarce) wysyajc danie na adres {adres
aplikacji}/html/strona.html, przy czym {adres aplikacji} to np. http://test.pl:8080/myApp.
W katalogu WEB-INF, w podkatalogu o nazwie classes umieszczamy w odpowiedniej
odpowiadajcej pakietom strukturze katalogowej skompilowane klasy, w tym servlety. Jeli do
implementacji aplikacji uywamy bibliotek spakowanych w archiwa JAR to biblioteki te umieszczamy
w podkatalogu lib.
W katalogu WEB-INF umieszczamy gwny plik konfiguracyjny aplikacji WWW, tzw. deskryptor
wdroenia. Jest to pokazany na powyszej ilustracji plik web.xml.
Deskryptor wdroenia to gwny plik konfiguracyjny aplikacji WWW. Jest to plik XML o nazwie
web.xml, ktry umieszczamy bezporednio w katalogu WEB-INF.
W deskryptorze wdroenia konfigurujemy midzy innymi adresy URL servletw. Wiemy ju, z
wczeniejszego opisu jak skonstruowa URL dla zapyta, dla ktrych w odpowiedzi odsyane s pliki
umieszczone bezporednio w katalogu gwnym aplikacji, ale w jaki sposb wysa danie HTTP do
servletu? Ot to, ktre dania zostan obsuone przez servlet konfigurujemy wanie w
deskryptorze wdroenia, tzn. w pliku web.xml. Poniej przykad:
<web-app version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<servlet>
<servlet-name>HelloServlet</servlet-name>
<servlet-class>pl.test.HelloWorldServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>HelloServlet</servlet-name>
<url-pattern>/hello</url-pattern>
</servlet-mapping>
</web-app>
Element o nazwie web-app to element nadrzdny, grupujcy wszystkie elementy konfiguracji.
Zawiera on niezbdne definicje w postaci atrybutw, w ktrych znaczenie nie potrzebujemy pki co
wnika z naszego punktu widzenia jest to element stay kadego pliku web.xml i zawsze wyglda on
tak samo (dla specyfikacji servletw w wersji 2.5).
To co nas szczeglnie interesuje, to element servlet oraz servlet-mapping.
Element servlet to definicja servletu; w pod-elemencie servlet-class podajemy pen (poprzedzon
nazw pakietu) nazw klasy ktra implementuje servlet, za servlet-name to dowolna, wymylona
przez nas nazwa. Nazwa servletu ktr wpisujemy jako warto pod-elementu servlet-name suy w
zasadzie tylko do tego, aby powiza definicj servletu z definicj mapowania na URL. Element
servlet-mapping to wanie definicja wzorca adresw URL, dla ktrych dania bd obsugiwane
przez powizany servlet. Uwaga! Element servlet-name wie definicj servletu z definicj
mapowania i jego warto musi by w obydwu tych definicjach taka sama.
W powyszym przykadzie skonfigurowalimy aplikacj WWW w ten sposb, e wszystkie dania
wysane na adres URL postaci {adres aplikacji}/hello zostan przekazane do servletu
pl.test.HelloWorldServlet i w odpowiedzi na takie danie zostanie do klienta odesana tre
wygenerowana w tym wanie servlecie.
W deskryptorze wdroenia konfigurujemy take szereg innych parametrw aplikacji. W szczeglnoci,
moemy umieszczajc w nim odpowiedni konfiguracj zabezpieczy aplikacj przed
nieautoryzowanym dostpem.
wiczenie 7. Samodzielnie wykonaj przykady opisane w Rozdzia 3 z podrcznika
http://docs.oracle.com/javaee/6/tutorial/doc/javaeetutorial6.pdf
wiczenie 9. Wdraanie aplikacji przy uyciu narzdzia CLI. Wykorzystujc servlet z wiczenia 5
uruchom go z poziomu linii komend.
Innym sposobem wdroenia aplikacji jest uycie narzdzia CLI (Command Line Interface), ktre
mona uruchomi za pomoc pliku jboss-cli.bat (lub jboss-cli.sh w przypadku uytkownikw systemu
Linux).
Jak nietrudno si domyli, do wdroenia aplikacji niezbdne bdzie uycie polecenia deploy.
Polecenie bez argumentw powoduje wywietlenie listy aktualnie wdroonych aplikacji.
[localhost:9999 /] deploy
ExampleApp.war
Jeli pierwszym parametrem polecenia bdzie archiwum z zasobami (na przykad lokalizacja pliku
.war), zostanie ono od razu wdroone na lokalnym, samodzielnym serwerze.
[standalone@localhost:9999 /] deploy ../HelloWorld.war
Jak mona si domyli z powyszego zapisu, narzdzie CLI uywa standardowo folderu, w ktrym
zostao uruchomione, czyli JBOSS_HOME/bin. Nic jednak nie stoi na przeszkodzie, by do wskazywania
lokalizacji archiww uywa penych cieek; obsuga przez narzdzie funkcji automatycznego
uzupeniania (klawisz Tab) dodatkowo uatwia cae zadanie.
[standalone@localhost:9999 /] deploy c:\deployments\HelloWorld.war
'HelloWorld.war' deployed successfully.
Domylnie wdroenie powoduje rwnie aktywacj aplikacji, wic jest ona od razu dostpna dla
uytkownikw. Jeli chce si jedynie wdroy aplikacj i aktywowa j pniej, konieczne jest
przekazanie opcji --disabled.
[standalone@localhost:9999 /] deploy ../HelloWorld.war --disabled
'HelloWorld.war' deployed successfully.
Aby uaktywni ju wdroon aplikacj, ponownie trzeba uy polecenia wdroenia bez opcji -disabled, a zamiast lokalizacji archiwum poda nazw wdroenia.
[standalone@localhost:9999 /] deploy --name=HelloWorld.war
'HelloWorld.war' deployed successfully.
wiczenie 10.
Stwrz analogiczny jak w zadaniu 5 projekt ale jako serwer aplikacyjny wykorzystaj
Apache Tomcat.
wiczenie 11. Napisz drugi Servlet, ktry bdzie stron startow naszego projektu (czyli bdzie
odpalany po uruchomieniu projekt na wybranym serwerze Aplikacyjnym) nazwa projektu dowolna.
wiczenie 12. Dodaj link w startowym Servlecie do TestServlet. (link definiujemy za pomoc <a
href=adres url>Tekst widoczny w przegldarce</a>).
wiczenie 13. Napisz servlet, ktry bdzie przyjmowa 5 liczb cakowitych metod GET, wyliczy ich
redni i zwrci wynik.
wiczenie 14. Napisz servlet, ktry bdzie przyjmowa dowoln ilo parametrw metod POST i
sprawdza, czy parametry te s liczbami. Jeli s, niech je wywietli w kolejnoci od najmniejszej do
najwikszej. Jeli parametry nie s liczbami, niech servlet zwrci informacje o bdnych danych.
sprawd co robi funkcja getParameterNames() i czy mona J wykorzysta j do pobierania dowolnej
iloci parametrw z requesta.