Programozás | Java, JSP » Angster Erzsébet - JSP alkalmazásfejlesztés

Adatlap

Év, oldalszám:2005, 42 oldal
Nyelv:magyar
Letöltések száma:706
Feltöltve:2008. október 12
Méret:558 KB
Intézmény:-

Csatolmány:-

Letöltés PDF-ben:Kérlek jelentkezz be!


Értékelések

Anonymus 2014. szeptember 26
  Thx.

Új értékelés

Tartalmi kivonat

1. Á ttekintés, fogalmak tisztázása Elosztott alkalmazá sok jegyzet II. rész JSP alkalmazá sfejlesztés Angster Erzsébet E rész elsajátí tásához elengedhetetlenek az alapvető HTML, háló zati és programozási ismeretek. Módosítá sok tö rténete Dá tum Fá jlnév Oldal Vá ltozá s előzőverzió hoz képest 2005.1214 JSP jegyzet-2005-12-14.pdf 31 Első kiadás 2005.1220 JSP jegyzet-2005-12-20.pdf 42 Csak a 30. oldaltó l változott Tartalomjegyzék 1. 2. Á ttekintés, fogalmak tisztá zá sa . 3 1.1 Háló zati alapfogalmak 3 1.2 HTTP erő forrásazonosító 5 1.3 Webalkalmazás 7 1.4 A HTTP kérés/válasz modellje 8 1.5 Java technoló giák 10 1.6 Mi a szervlet? 11 1.7 Mi a JSP? 15 1.8 Mi kell egy JSP program futtatásához? 17 Javá s webalkalmazá sok futtatá sa. 19 2.1 A Tomcat webszerver telepítése 19 2.2 A webszerver elindítása, leállí tása 21 2.3 A webszerver mapparendszere 23 2.4 A webalkalmazás felépítése 23 1 1.

Á ttekintés, fogalmak tisztázása 4. 2.5 Webalkalmazások telepítése és futtatása 25 2.6 Szervletek futtatása 29 2.7 Egy nagyobb alkalmazás telepítése és futtatása – OOK 31 2.8 Tesztkérdések 35 2.9 Feladatok 35 A JSP lap elemei. 36 3.1 Mintaprogram 36 3.2 A JSP lap elemei 40 3.3 Megjegyzések 40 3.4 Direktí vák 40 3.5 Szkriptek 41 3.6 Akció k 43 3.7 Változó k, ható kö rö k 43 3.8 A JSP lap elő re definiált változó i 43 3.9 Kérési paraméter használata 44 3.10 A generált szervlet 46 3.11 Ha nem megy a futás 47 3.12 Tesztkérdések 47 3.13 Feladatok 48 HTML formok és EJB objektumok között adatcsere. 49 5. Lapok á tirá nyítá sa, ható körök . 52 6. Szervletek és JSP lapok . 53 7. Kapcsoló dá s az adatbá zishoz. 54 3. 8. Egy nagyobb alkalmazá s elemzése . 55 8.1 Feladat – Egy szakmai klub honlapja 55 8.2 Használati esetek 55 8.3 Az OOK architektúrája 55 9. A JSP programok tipikus architektú rá ja, tervezési

elemei 56 9.1 Rétegek 56 9.2 J2EE minták 56 9.3 Az OOK architektúrája 56 9.4 A kész alkalmazás publikálása?? 56 10. Függelék – HTML kisokos 58 11. Függelék – JSP fordítá si direktívá k 59 12. Hivatkozá sok, ajá nlá sok 60 2 1. Á ttekintés, fogalmak tisztázása 1. 1.1 Á ttekintés, fogalmak tisztá zá sa Há lózati alapfogalmak Foglaljuk ö ssze rö viden az elő ző részbő l azokat a legfontosabb fogalmakat, melyeket ebben a részben intenzí ven használunk: Kiszolgá ló : más néven szerver (server). Aki/ami az ügyfél által kért feladatot elvégzi, vagyis kiszolgálja az ügyfelet. Ü gyfél: más néven kliens (client). Aki/ami a kiszolgáló t megkéri a feladat elvégzésére Kiszolgá ló szá mító gép: Háló zati csomó pontban lévő számító gép, mely lehető vé teszi, hogy a háló zathoz csatlakozó kliens számí tó gépekrő l valamely osztott erő forrást használni lehessen. A szerver számí tó gép a rajta

levő szerver programok segítségével szolgálja ki a klienseit. Ü gyfél szá mító gép: Valamely szerver számító géppel háló zati kapcsolatban álló számító gép. A kliens számí tó gép a rajta levő kliens szoftver segítségével szó lítja meg a szervert, és kér tő le szolgáltatásokat. Kiszolgá ló szoftver: Szoftver, amely kiszolgálja a klienseit, vagyis válaszol a kliens szoftver kérésére. A szerver szoftver sohasem szó lítja meg a klienseit, ő csak válaszol a kérésekre A szerver szoftver jellemző en szerver számító gépen fut. Ü gyfél szoftver: Olyan szoftver, mely alkalmas arra, hogy kéréseket intézzen valamely kiszolgáló szoftverhez. IP (Internet Protokol) cím: Az internetbe kapcsolt számító gép (pontosabban háló zati kártya) állandó vagy ideiglenes azonosí tó ja. Négy (vagy hat) darab, 0 és 255 kö zö tti decimális számbó l áll, melyeket pontok választanak el egymástó l, és az internet címkereső gépei a

számí tó gépek azonosí tására használják. A szerver gépeknek fix (állandó ) IP címük van, amelyet az internet szolgáltató k tartanak nyilván. A kliens géphez az internet szolgáltató a kapcsolat felvételekor rendel egy IP címet, mely a kapcsolat végéig érvényes. Például: 81.7895174 vagy 157181151154 IP címtartomá ny: Az internetbe kapcsolt számító gépek hierarchikus cí mrendszerének egy szintje. Egy ország vagy egy szervezet például kaphat egy IP címtartományt Egy IP cí mtartományhoz az internet szolgáltató k egy ö sszetett logikai nevet, ún. domén-nevet rendelnek. 3 1. Á ttekintés, fogalmak tisztázása Domén-név: Ö sszetett logikai név, melynek részei egyre bő vülő IP címtartományokat határoznak meg (például ttk.eltehu) A teljes domén-név meghatároz egy IP címet (például a ttk.eltehu IP cí me 157181151153) A jobb oldali rész-címek meghatározzák a bennfoglaló kö vetkező szintet (például: ttk.eltehu 

eltehu  hu) A teljes domén-név tehát egy számí tó gépet azonosí t, a balró l levágott domén-nevek pedig egy-egy számító gép-tartományt. A legfelső szintű domén (jobb oldali rész-név) általában egy országot vagy egy nagy szervezetet azonosí t (például hu, de, com, org). Például a hu tartományba tartozik az sdpcityhu, a medzihu és az eltehu Gazdagép (host computer): IP cí mmel azonosítható számító gép. Egy gazdagépen tö bb domén is „lakhat”. Például a 827996173 gazda számító gépen található tö bbek kö zö tt az sdpcityhu és a medzihu domén is Resource (erőforrá s): Bármi, amit egy szerver számító gép „kiad” a kliens számára. Erő forrás lehet egy dokumentum, egy kép, egy program, vagy egy program által elő állított bájtsorozat. Domén (domain): Erő forrás-halmaz, melyet az ún. domén-név azonosít Például: sdp-cityhu, ttk.eltehu Domén alatt általában a teljes domén-névvel azonosított erő

forráshalmazt értik Egy szerver számí tó gépen általában tö bb domén is helyet kap (például a 82.7996173 számí tó gépen található az sdp-city.hu és a medzihu domén) Egy domén tö bb számító gépet is elfoglalhat (például fw.hu), ekkor a domén IP címe egy elosztó számító gépet azonosít Hasznos lehet néhány DOS parancs számító gépek teszteléséhez, valamint IP címének kiderí téséhez. Ehhez nyisson egy konzolablakot! − Saját számí tó gép IP cí me, statisztikája: ipconfig − Egy távoli számí tó gép IP cí me, statisztikája: ping [<IP cím>/<domén-név>] − A saját számí tó gép elérési statisztikája: ping localhost Például nézzük meg, melyik számí tó gépen „tartó zkodik” az sdp-city.hu domén (ehhez persze szükséges, hogy a kérdező gép be legyen kapcsolva az internetbe)! C:>ping sdp-city.hu sdp-city.hu [827996173] DNS (Domain Name Server, névkiszolgá ló ): Kiszolgáló szoftver,

melynek az a feladata, hogy az IP cí meket és a domén neveket megfeleltesse egymásnak. A ping parancs például egy DNS-t kér meg az IP cí m megadására. URI (Universal Resource Identifier, egységes erőforrá s azonosító ): Más néven URL (Universal Resource Locator, egységes erő forrás helymeghatározó ). Egy erő forrást azonosí t az interneten. Az URI két részbő l tevő dik ö ssze: séma: erőforráscím A séma meghatározza az erő forrás címképzési szabályrendszerét. A séma általában egy kommunikáció s protokoll. Ismert kommunikáció s protokollok: http, ftp, file, mailto, gopher, telnet, news. Az erő forráscí m az adott kommunikáció s protokoll szabályrendszere szerint meghatároz egy konkrét erő forrást. 4 1. Á ttekintés, fogalmak tisztázása HTTP: Egy kommunikáció s protokoll, mely elő írja az ügyfél és a kiszolgáló szoftverek webes kommunikáció jának mó dját. Webkiszolgá ló (webszerver, HTTP kiszolgá ló ):

Olyan kiszolgáló szoftver, amely az ügyfél számára HTML oldalakat küld. A két leggyakrabban használatos HTTP kiszolgáló pillanatnyilag az Apache (multiplatformra) és az IIS (Internet Information Server, Windowsra). A HTTP protokollban megadott erő forrás általában távoli gépekrő l is elérhető ; a file protokollban megadott erő forrás (file://állományspecifikáció ) a bö ngésző t futtató gépen van. A file protokollt akkor szokás használni, ha a bö ngésző bő l csak a saját gép erő forrásait szeretnénk elérni. 1.2 HTTP erő forrá sazonosító HTTP kommunikáció s protokoll esetén az erő forrásazonosítás szintakszisa a kö vetkező : http://<domén-név>|<IP cím>[:<kapu>][/<állományspecifikáció>] Jelentések: − domé n-né v vagy IP cím: Egy számító gépet (gazdagépet) azonosít. A helyi számító gép domén-neve localhost, IP cí me 127.001 − kapu (port): Egy szám, amely egy kiszolgáló

szoftvert azonosít a gazdagépen. Alapértelmezés: 80, amely egy HTTP szerver azonosító ja. − állományspecifikáció : Az adott gépen található erő forrás (állomány) relatív elérési útvonala. A relatí v útvonal a szerver gyö kérkö nyvtárábó l indul A gyö kérkö nyvtár alapértelmezett helye a szerverprogram konfiguráció játó l függ. Szintaktikája Windowsban: [/<mappa>[/<mappa>.]] [<állománynév>[<kiterjesztés>]] Jelö lések: <> behelyettesí tendő , | vagy, [] elhagyható , . akárhány megadható Például: A 8080-as kapun a Tomcat szerverbe jutunk, ahol az alapértelmezett kö nyvtár: <TOMCAT HOME>/webapps. Egy szerverprogramnak vannak alapértelmezései mind a kiterjesztést, mind a fájlnevet illető en; ezek az alapértelmezések általában a szerverprogram konfiguráció s állományában található k. Ha például az állományspecifikáció egy kö nyvtárt azonosít, akkor egy webszerver az

index.html lapot adja oda HTTP erő forrás-azonosí tó k például: http://81.7895174/szolgaltatasok/regisztracio http://localhost:8080/OOK http://sdp-city.hu/ http://sdp-city.hu http://sdp-city.hu:8080/ http://81.7895174:5029 5 1. Á ttekintés, fogalmak tisztázása Az erő forrást egy – a gazdagépen futó – folyamat kapja meg feldolgozásra (1.1 ábra) A szerverprogram és az erő forrás azonosítása a HTTP erő forrásazonosító alapján a kö vetkező lépésekben tö rténik: 1. 2. 3. 4. A domén-név vagy IP cí m meghatároz egy számító gépet (a gazdagépet). Ez lehet akár távoli, akár helyi gép. A számí tó gépen futó folyamatokat (szerverprogramokat) az operáció s rendszer kapuszámokkal azonosí tja (két szoftver nem indulhat el ugyanazon a kapuszámon). Az operáció s rendszer odaadja az erő forrást a megadott kapuszámú folyamatnak feldolgozásra. A szerverprogram minden doménhez, illetve a localhosthoz hozzárendel egy gyö kérkö

nyvtárat (root dir). Az állományspecifikáció ebbő l a kö nyvtárbó l indul Ha az erő forrásazonosí tó egy programot azonosít, akkor azt a szerverprogram lefuttatja, és a program kimenetét adja át a kliensnek, egyébként pedig magát az erő forrást. 1.1 ábra A szerverprogram és az erő forrás azonosítása A kapu a szerver program „bejárata”. Egy szerver számító gépen rengeteg szerver szoftver futhat. Még egy személyi számító gépen is gyakori, hogy egyszerre fut egy webszerver, egy alkalmazás-szerver, egy adatbázis szerver és egy mail szerver. Az is nyugodtan elő fordulhat, hogy tö bb „azonos nemű” szerver, például tö bb adatbázis-szerver (mysql, interbase, oracle.) is fut egyszerre. Egy szolgáltató gépén általában ennél sokkal tö bb szerver is fut egyidő ben – elképzelhető , hogy csak webszerverbő l fut ö tféle. A kapu (port) a szerver alkalmazásokat azonosí tja egy adott számí tó gépen. Amikor egy szervert

elindítunk, meg kell adni egy kapuszámot – olyant, amilyennel még nem fut a számító gépen szerver program. A szerver általában a telepí téskor megadott kapuszámon kezd el futni. 6 1. Á ttekintés, fogalmak tisztázása A http://localhost:8080/OOK például a helyi számító gépen futó szervereket végignézi, és az első olyan szervernek odaadja a kérést, amelynek kapu-azonosító ja 8080. S mivel a „talált” szerver egy Tomcat webszerver lesz, a localhost gyö kérkö nyvtára (TOMCAT HOME) alatti OOK kö nyvtárban levő index.jsp lapot fogja odaadni a kliensnek – a Tomcat alapértelmezett lapja ugyanis az index.jsp Vannak foglalt és ajánlott kapuszám-tartományok. A Tomcat webszerver alapértelmezett kapuszáma a 8080, vagyis ha ezt a kapuszámot a telepített Tomcat-ben nem írták át, akkor az a 8080-as kapun fogadja a parancsokat. Ez azt jelenti, hogy ha az URI-be ezt a kapuszámot í rjuk be, akkor nagy való szí nűséggel egy Tomcat-be

„botlunk”. Nem ajánlatos ezt a kapuszámot felülbí rálni, mert ha a szokásostó l eltérő kapuszámon futtatunk egy szervert, akkor a kliensek nem fogják megtalálni. Egy szerver megszó lí tásához a bö ngésző ben meg kell adnunk a számító gépet (domén-nevet vagy IP cí met), valamint a kaput. Egy HTTP szerver alapértelmezett kapuszáma a 80, az a szám, ami a HTTP erő forrás-azonosí tó ban is alapértelmezett. Ha tehát a kliens bö ngésző ben nem adunk meg kapuszámot, és a HTTP szerver is alapértelmezés szerint műkö dik, akkor az erő forrást egy HTTP szerver kapja meg feldolgozásra. 1.3 Webalkalmazá s Webalkalmazá s: Alkalmazás (program), amely egy webkiszolgáló n fut, s amely felhasználó i felületét egy általános célú ügyfél alkalmazás, például egy bö ngésző adja (1.2 ábra) 1.2 ábra A webkiszolgáló futtatja a webalkalmazást 7 1. Á ttekintés, fogalmak tisztázása A webalkalmazás futtatásakor az a cél, hogy

a bö ngésző nkben meg tudjunk jeleníteni egy távoli gépen futó webkiszolgáló szoftver által – a kérési paraméterektő l függő en – „legyártott” dinamikus információ t. Mint tudjuk, statikus információ megjelenítéséhez bő ven elegendő a HTML lapok használata. A dinamikus megjelenítés azt jelenti, hogy a megjelení tett lap tartalma a futtatási kö rülményektő l függő en más és más lehet. A felhasználó lekérdezhet például konkrét adatokat, mely adatoktó l függő en aztán más és más lehet a kö vetkező re ö sszeállí tott weblap (például kimutatás). A kiszolgáló a kérést saját konfiguráció s beállításai alapján értelmezi és elégíti ki. A legegyszerűbb eset, ha csak visszaküld egy statikus lapot Ha azonban az URI egy programot azonosí t (lásd 1.2 ábra), akkor lefuttatja a programot, és az általa elő állított lapot küldi vissza az ügyfélnek. A JSP lap is egyfajta program Egy egyszerű webalkalmazás

futtatásához elegendő maga a bö ngésző . Bizonyos webalkalmazások futtatásához azonban csatlakoztatni kell a bö ngésző hö z más programokat is (ezek az ún plugin programok, például képmegjelenítő , pdf olvasó vagy java virtuális gép). 1.4 A HTTP kérés/vá lasz modellje A HTTP protokoll elő í rja az ügyfél és a kiszolgáló kö zö tti kommunikáció mó dját. Azt már tisztáztuk, hogy a kérésben megszó lí tott kiszolgáló szoftver és az erő forrás azonosítását az URI kö zvetí ti. Most arró l lesz szó , hogy az ügyfél milyen adatokat küldhet át a kéréssel együtt, és milyen mó don kap választ. Kérés (request) A felhasználó nak a kö vetkező lehető ségei vannak, hogy elküldjö n egy kérést a kiszolgáló hoz: − A bö ngésző cí msorába beí r egy erő forrás-azonostító t (URL-t). Az URL végére paramétereket is í rhat. − A HTML lapon rákattint egy linkre. A link végén paraméterek is szerepelhetnek − A

felhasználó a HTML lapon rákattint egy SUBMIT gombra. Az első két esetben a kérés ún. GET eljárással megy el a szerverhez, a harmadik esetben POST eljárással. A HTTP protokoll szerint ugyanis az ügyfél alapvető en ezen eljárások egyikével küldheti el kérését a szervernek (tö bb mó dszer is van, de azokkal most nem foglalkozunk). A két eljárás kö zö tti alapvető külö nbség, hogy − GET esetén a paramétereket az URI tartalmazza (a kérdő jel után), például: http://www.googlecom/search?hl=en&lr=&q=tomcat+download&btnG=Search − POST esetén az URI „tiszta”, nincsenek hozzáfűzve a paraméterek végeláthatatlan ö sszevisszasága. A paraméterek rejtve vannak, azokat a felhasználó nem látja A HTTP kérés ö sszeállí tása a bö ngésző feladata. Elö ljáró ban nézzünk meg a bö ngésző által ö sszeállí tott két kérést: az egyiket GET, a másikat POST metó dussal kérték. Egy GET-bő l ö sszeállí tott

kérés: 8 1. Á ttekintés, fogalmak tisztázása GET /index.html?user=Jani&pw=Nenezz HTTP/10 Host: sdp-city.hu User-Agent: Opera Accept: image/jpeg Accept-language: en Accept-charset: iso-8859-2 Egy POST-bó l ö sszeállí tott kérés: POST /index.html HTTP/10 Host: sdp-city.hu User-Agent: Opera Accept: image/jpeg Accept-language: en Accept-charset: iso-8859-2 user=Jani pw=Nenezz A HTTP protokoll pontosan elő í rja a kiszolgáló nak küldö tt kérés részeit, formátumát. Az átküldendő adatokat az ügyfélprogramnak „ö ssze kell szednie” (URI-bó l, ügyfél programtó l stb.), és csoportosí tania kell azokat a HTTP protokoll elő írásai szerint Egy HTTP kérés részei a kö vetkező k (eljárástó l függetlenül): − Kérés sora: Elö l szerepel a kérési metó dus neve (GET, POST.), utána az erő forrás útvonala paraméterekkel, majd a protokoll verzió ja. Az erő forrás lehet egy statikus állomány, program, vagy más. Az erő forrás

pontos beazonosítása a webkiszolgáló dolga. − Fejlécek (vastagon szedve): Ebben található k az ügyféllel (bö ngésző vel) kapcsolatos adatok, mint például a bö ngésző típusa. A feladat konkrét végrehajtásához a kiszolgáló nak szüksége lehet ezekre az adatokra − Törzs: A fejlécektő l egy üres sor választja el. Csak akkor van tö rzs, ha a kérés a POST eljárással került ö sszeállí tásra. A tö rzs minden egyes sora egy paraméter: név=érték párosok. Ha az elkért erő forrás program, akkor annak szüksége lehet az itt megadott futási adatokra. A kérés angol neve: request. A kö nyv késő bbi részeiben gyakran fogunk hivatkozni ilyen nevű objektumra. Egy HTTP kérés alapvető eljárásai a kö vetkező k: − GET: A kérés egy link megadásával indul, ahol a link tartalmazza az URI-t és az esetleges paramétereket. A linket megadhatjuk a bö ngésző címsorában, vagy egy lap (HTML, XML.) elemeként Az alapértelmezett mó dszer

a GET, vagyis ha a cí msorba csak egy csupasz URI-t í runk be, akkor az GET mó dszernek minő sül. A GET mó dszer esetén paramétereket csak az URI végén, egy lekérdezési karakterláncban adhatunk meg. A lekérdezési karakterlánc kezdetét a ? jelzi, ezután kö vetkeznek a név=érték párosok, & jellel elválasztva. Például: http://localhost:8080/mintaprogramok/akarmi.jsp?nev=Alajos&szulev=1976 9 1. Á ttekintés, fogalmak tisztázása − POST: A kérés a SUBMIT gomb lenyomására indul. Ebben az esetben a paramétereket jellemző en a HTML formok mező i szolgáltatják, de az URI végén is megadható k paraméterek. Az ügyfélprogram (például a bö ngésző ) a kérés ö sszeállításakor a form mező inek (név, érték) párosait a tö rzsben helyezi el. A HTTP állapot nélküli protokoll. Ez azt jelenti, hogy a kiszolgáló a kérés teljesítése után semmit nem jegyez meg a kérésbő l. Az ügyfél tehát minden egyes kéréskor „üres

lappal” indul. Vá lasz (response) Egy válasz például: HTTP/1.0 200 OK Last-Modified: Date: Status: Content-Type: Servlet-Engine: Content-Length: <html> <body> Ez egy HTML lap. </body> </html> A HTTP válasz részei a kö vetkező k: − Á llapotsor: Elö l szerepel a protokoll verzió ja, ezt kö veti az eredmény kó dja és leírása. − Fejlécek (vastagon szedve): A válaszra jellemző adatok, mint az elküldö tt lap utolsó mó dosí tásának dátuma, a tartalom típusa stb. − Törzs: A tö rzset a fejlécektő l egy üres sor választja el. A tö rzs maga a megjelenítendő erő forrás, például egy HTML lap. A kérés angol neve: response. A kö nyv késő bbi részeiben gyakran fogunk hivatkozni az ilyen nevű objektumra. 1.5 Java technológiá k Alapvető rö vidítések − JRE (Java Runtime Environment): Java futtatási kö rnyezet. Alapcsomag a Java programok futtatásához Tartalmazza a virtuális gépet és az alapvető API-kat

− SDK (Software Development Kit): Szoftverfejlesztési csomag. Java programozá si nyelv A Java programozási nyelv segí tségével vállalkozás-értékű programokat lehet írni, amelyek futnak akár bö ngésző ben, akár asztali számító gépen, szerveren vagy valamely fogyasztó i 10 1. Á ttekintés, fogalmak tisztázása eszkö zö n fut. Egy Java programot nem kö zvetlenül a natív operáció s rendszer futtat, hanem a Java virtuális gép (JVM), biztosítva ezzel a platformfüggetlenséget. Java platform A Java platform egy szoftverekbő l álló kö rnyezet, amely egy adott hardver kö rnyezetre épül, és Java alkalmazások fejlesztését és/vagy telepítését célozza. Mivel a hardver platformok nagyon specifikusak (más a memó ria, tárolási mó dszer, háló zati csatlakozás stb.), a külö nbö ző hardver kö rnyezetekre speciális Java platformok készülnek Minden egyes platform a speciális hardver kö rnyezet Java virtuális gépén alapszik.

Ezért, ha egy tetsző leges platformon megí runk egy Java programot, az mó dosítás nélkül futtatható egy JVM-mel rendelkező másik hardver kö rnyezetben. Java technológiá k A Java technoló gia egyszerre jelenti magát a programozási nyelvet és a külö nbö ző alkalmazásfejlesztési és -futtatási platformokat. A Java technoló gia szabványos megoldásokat ad biztonságos, hordozható , megbí zható és skálázható alkalmazások fejlesztésére és telepítésére, elosztott kö rnyezetben. Fő bb Java technoló giák: − J2SE, Java 2 platform, Standard Edition (normál kiadás). A Java maghoz és az asztali alkalmazások elkészí téséhez biztosítja a szoftver kö rnyezetet. Erre a platformra épül tö bb más technoló gia, mint például J2EE. A J2SE részét képezik a kö vetkező elemek: Java fordí tó program; futtatáshoz szükséges segédprogramok; Java API-k az alkalmazások és appletek í rásához, teszteléséhez, telepítéséhez és

futtatásához. − J2EE, Java 2 platform, Enterprise Edition (vállalati kiadás). Szabványokat ad és szoftver kö rnyezetet biztosít komponens alapú, tö bbrétegű, elosztott vállalati alkalmazásokhoz A J2SE-n alapszik, és további szolgáltatásokat, eszkö zö ket és API-kat tartalmaz a vállalati alkalmazások elkészí téséhez. − J2ME, Java 2 platform, Micro Edition (mikro kiadás). Szabványokat ad és szoftver kö rnyezetet biztosí t fogyasztó i és beágyazott eszkö zö k (pl mobil telefonok, PDA-k, printerek) programjainak fejlesztésére és telepítésére A Java technoló giák áttekintése a Sun oldalán megtalálható : http://java.suncom/overviewhtml 1.6 Mi a szervlet? A szervlet technoló gia a J2EE technoló gia szerves része, mellyel szerveroldali Java programokat lehet í rni. A HTTP szervletek arra való k, hogy javás, webes alkalmazásokat készítsünk (itt mindegyik szó nak súlya van): − javás: Ezek az alkalmazások a szerver oldalon

tudnak javául. − webes: Az ügyfél webes felületen (bö ngésző segí tségével) kommunikál az alkalmazással. − alkalmazás: Programró l van szó , dinamikus megjelenítésrő l. A bö ngésző kérésére az alkalmazás HTML lapokat „gyárt” a webkiszolgáló kö zreműkö désével. 11 1. Á ttekintés, fogalmak tisztázása javax::servlet::Servlet <interfész> init(ServletConfig) service(ServletRequest, ServletResponse) destroy() . java::lang::Object javax::servlet::GenericServlet {abstract} init(ServletConfig) service(ServletRequest, ServletResponse) destroy() . getInitParameter(String): String getInitParameterNames(): Enumeration javax::servlet::http::HttpServlet {abstract} service(HttpServletRequest, HttpServletResponse) doGet(HttpServletRequest, HttpServletResponse) doPost(HttpServletRequest, HttpServletResponse) . 1.3 ábra A szervletek alapvető osztályai A Java szervlet egy szerver oldali Java „programocska” (class állomány), mely a

kliensek kéréseire válaszokat küld. Mí g az applet egy kliensoldali, a szervlet szerveroldali program A szervletet a szerver konténer hajtja végre, és sok esetben HTML állományt állít elő . A szervlet egy Java osztály, mely a servlet API interfészeibő l és osztályaibó l „építkezik”. Egy szervletnek implementálnia kell a Servlet interfészt, melynek legfontosabb metó dusai az ún. életciklus metó dusok: az init, a destroy és a service; ezeket a webkiszolgáló hívja meg a kérés érkezésekor. A service metó dus println metó dusok hívásaival elkészítheti a webszerver által szolgáltatandó dinamikus HTML lapot. A service metó dus készen kapja a request és response objektumokat, melyeket felhasználhat a lap készítése során. A GenericServlet absztrakt osztály egy alapértelmezett megvaló sítását adja a Servlet interfésznek; csak a service metó dust „hagyja nyitva”. A HttpSzervlet osztály a GenericServlet leszármazottja, mely

további segítséget ad a HTTP kérések teljesí téséhez. Szervletet legegyszerűbben úgy tudunk írni, ha a kibő vítjük a GenericServlet vagy a HttpServlet osztályt, és megí rjuk annak service metó dusát. 12 1. Á ttekintés, fogalmak tisztázása Szervleteket futtató programot szervlet konténernek szokás nevezni. Ha a webkiszolgáló (más néven webkonténer) szervletet futtató kérést kap, akkor a kérést átadja a szervlet konténerének, aki a szervletet betö lti és végrehajtja. A szervlet a végrehajtáshoz két paraméterobjektumot kap: egy kérést (request) és egy választ (response) Az életciklus metó dusokat a javax.servletServlet interfész definiálja, és a szervlet-konténer hí vja meg. Feladataik: − init: inicializálja a szervlet objektumot; elő készíti ő t a kérések fogadására. − servive(request, response): A szervlet-konténer minden egyes kéréskor ezt a metó dus hí vja meg. A kérés és válasz objektumait

paraméterben adja át − destroy: Végrehajtja a szervlet befejező metó dusait. Ezután a szervlet már nem kap tö bb kérést. A servlet API implementáció ja, a servlet.jar csomag megtalálható a TOMCAT HOME alatti common kö nyvtárban. A 22-es Servlet API a kö vetkező címen érhető el: http://java.suncom/products/servlet/22/javadoc/ A kö vetkező egyszerű kis példa egy Java szervlet műkö dését mutatja be. Feladat Készí tsü nk egy szervletet, amely elkészí ti a képen lá tható HTML lapot! A szervlet futtatásával még egy kicsit várnunk kell; ahhoz telepíteni kell majd egy Javás webszervert. A program futását ezért csak a kö vetkező fejezetben fogjuk kipró bálni Figyelje meg, hogy a bö ngésző cí msorába ezt írtuk: http://localhost:8080/mintaprogramok/servlet/fej02.Hurra A kö vetkező fejezetben majd erre is lesz magyarázat. hurra.java package fej02; import import import import javax.servlet*; javax.servlethttp*; java.io*; java.util*;

//1 13 1. Á ttekintés, fogalmak tisztázása public class Hurra extends HttpServlet { public void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); //2 //3 //4 //5 out.println("<html>"); //6 out.println("<head>"); out.println("<title>Hurrá</title>"); out.println("</head>"); out.println("<body bgcolor=lightgray>"); out.println("<h1>Hurrá!</h1>"); out.println("Sikerült elindítanom egy webalkalmazást!<br>"); out.println("<hr size=5 color=BLUE>"); for (int i=1; i<=3; i++) out.println("ingyom bingyom táliber<br>"); //7 out.println("</body>"); out.println("</html>"); //8 } } A forrá skód elemzése ¨ //1: A Hurra osztály használja a

javax.servlet csomagot (ebben van például a Servlet interfész és a ServletException osztály), és a javax.servlethttp csomagot (ebben van a HttpServlet osztály). ¨ //2: A Hurra egy HttpServlet. ¨ //3: csak a service metó dust í rjuk át. Ezt a metó dust majd a kiszolgáló fogja meghívni, és hí váskor a programozó rendelkezésére bocsátja a kérés (request) és a válasz (response) paramétereket. ¨ //4: A válasz kontextusa text/html. ¨ //5: A választó l elkérünk egy writert, hogy használhassuk a println metó dust. ¨ //6: Az out.println metó dusokkal építjük fel a HTML lapot Ugyanúgy írunk, mintha a konzolra í rnánk. A HTML lap felépítéséért mi vagyunk a felelő sek ¨ //7: Kö zben í rhatunk bármilyen Java kó dot. A fenti szervlet futásának eredménye a kö vetkező HTML lap: <html> <head> <title>Hurrá</title> </head> <body bgcolor=lightgray> <h1>Hurrá!</h1> Sikerült elindítanom egy

webalkalmazást!<br> <hr size=5 color=BLUE> ingyom bingyom táliber.<br> ingyom bingyom táliber.<br> ingyom bingyom táliber.<br> </body> </html> 14 1. Á ttekintés, fogalmak tisztázása A HTML lap pontos tartalmáró l meggyő ző dhet a bö ngésző View Source Page parancsával. 1.7 Mi a JSP? A JSP (Java Server Pages) egy technoló gia – a J2EE technoló gia szerves része, és a szervlet technoló giára épül. A JSP technoló gia lényege, hogy a weblap sorait nem egy szervlet készí ti kö zvetlenül, hanem az elkészí thető bármilyen „hagyományos” mó dszerrel, és az esetleges dinamizmus (program) a weblap sorai kö zé ékelő dik be. Így a webkiszolgáló által küldö tt weblap statikus részeit nem a programozó (a szervlet író ja) állítja ö ssze, hanem egy erre a feladatra specializáló dott webszerkesztő . A JSP technoló gia használatával külö n lehet választani a webszerkesztő és programozó

munkáját, aminek eredményeként sokkal hatékonyabban lehet a kor kívánalmainak megfelelő dinamikus weblapokat készí teni. A kö vetkező egyszerű kis példa egy JSP lapot mutat be. Feladat Készí tsü nk egy JSP lapot, mely elkérésére a képen lá tható lap jelenik meg – ugyanaz, mint az elő ző pontban tá rgyalt feladatban! A JSP futtatásával is várnunk kell a kö vetkező fejezetig. Jó l látható , hogy az elő állított kép ugyanaz, mint amit az elő ző pont szervlete állított elő . Figyelje meg, hogy most a bö ngésző cí msorába ezt írtuk: http://localhost:8080/mintaprogramok/fej02/Hurra.jsp hurra.jsp <html> <head> <title>Hurrá</title> </head> <body bgcolor=lightgray> <h1>Hurrá!</h1> Sikerült elindítanom egy webalkalmazást! <br> <hr size=5 color=BLUE> 15 1. Á ttekintés, fogalmak tisztázása <% for (int i=1; i<=3; i++) out.println("ingyom bingyom

táliber<br>"); %> </body> </html> Ez a JSP kó d annyival tö bb, mint egy normál HTML kó d, hogy van rajta egy JSP kó drészlet (vastagon szedett rész). Ez a kó drészlet tö rténetesen egy JSP szkript, melyet a <% vezet be, és a %> zár le. Amikor elkérünk egy JSP lapot, akkor a JSP értelmező szervletet készít belő le, majd lefordítja és futtatja azt (1.4 ábra) A bö ngésző végül egy kész, programkó dot már nem tartalmazó weblapot lap megjelení tésre. Mindkét technoló gia (szervlet és JSP) esetében tehát a weblapot egy szervlet készí ti, csak a JSP technoló gia esetében ez a színfalak mö gö tt zajlik. A JSP lapra csak annyi programkó dot ajánlatos rátenni, amennyi feltétlenül szükséges. Amit csak lehet, rejtsünk a színfalak mö gé, normál Java osztályokba! A JSP lapró l aztán speciális szabályok szerint lehet meghí vni az osztályok által megvaló sított normál metó dusokat, illetve akció

kat. A JSP lapokat értelmező és szervletté alakító programot JSP konténernek szokás nevezni. Ha a webkiszolgáló JSP-t futtató kérést kap, akkor a kérést átadja a JSP konténerének. 1.4 ábra A JSP lap átalakítása és futtatása Egy JSP lap annyival bő vebb, mint egy webes (HTML, XML vagy bármi más) lap, hogy azon JSP kó d található . A lap JSP-n kí vüli része a sablonszö veg, melyet a JSP kó d bárhol megsza16 1. Á ttekintés, fogalmak tisztázása kí that. A JSP-t értő webkiszolgáló a JSP lapbó l sablonszö veget állít elő úgy, hogy a lap eddigi sablonszö vegét figyelembe véve a JSP lapon levő kó dot futtatja. Egy JSP alkalmazást a bö ngésző bő l indítva futtatunk úgy, hogy a háttérben futó , JSP-t értő webszervertő l JSP lapokat kérünk el. A webszerver, mielő tt átadná a bö ngésző nek a JSP lapot, a lapon levő JSP kó dot lefuttatja, és a kó d helyére a bö ngésző által értelmezhető kó dot (pl. HTML

kó dot) illeszt be Egy JSP lapnak jsp a kiterjesztése, és a normál, HTML kó don kívül JSP kó dot is tartalmaz(hat). A hurra.jsp nevű JSP alkalmazás futtatásával is kicsit várnunk kell egy kicsit Egyelő re csak képzeljük el, hogy ez a JSP lap ott ül valahol a webszerver gyö kérkö nyvtárának minta nevű mappájában. Ha ezt a JSP lapot elkérjük a webszervertő l (a bö ngésző be írt kérési paranccsal: http://localhost:080/hurra/hurra.jsp), akkor a webszerver lefuttatja a JSP kó drészletet, mely alapján ezt a HTML lapot állí tja elő (kissé rendetlen, de hát „ez van” – szerencsére ez a lap kinézetét ez nem befolyásolja): <html> <head> <title>Hurrá</title> </head> <body bgcolor=lightgray> <h1>Hurrá!</h1> Sikerült elindítanom egy webalkalmazást! <br> <hr size=5 color=BLUE> ingyom bingyom táliber.<br> ingyom bingyom táliber.<br> ingyom bingyom táliber.<br>

</body> </html> A bö ngésző már ezt a „lefuttatott” lapot kapja meg, amire a már látott kép tárul elénk. 1.8 Mi kell egy JSP program futtatá sá hoz? Egy JSP alkalmazást csak egy JSP-t értő webszerver képes futtatni. Ilyen webkiszolgáló nem is egy van (pl. Tomcat, Velocity, JBoss, Blazix, SimpleW stb), de mi most a Sun által kifejlesztett, nyí lt, java forráskó dú, referenciaként szolgáló Apache Tomcat webszervert fogjuk műkö dtetni. A Tomcat az Apache Jacarta Project keretében készült webszerver, más néven webkonténer (Servlet és JSP konténer egyben). Egy JSP alkalmazás futtatásához a webszerveren kí vül szükség van Java futtató kö rnyezetre is, hiszen a JSP kó drészletek, és fő leg ami mö gö tte van, java kó d. Ráadásul a Tomcat egy Java alkalmazás, ezért az ő futásához is szükség van egy Java virtuális gépre. 17 1. Á ttekintés, fogalmak tisztázása Egy JSP program futtatásához szükségünk van

a kiö vetkező kre (1.5 ábra): a szerver számí tó gépen − egy JSP-t értő webszerverre (webkonténerre); − egy Java futtató kö rnyezetre és API-ra. A Tomcat esetében elegendő a J2SE is, mert a J2EE technoló giához kapcsoló dó dolgokat saját maga is telepíti. a kliens számí tó gépen pedig − egy bö ngésző re. A szerver és a kliens számí tó gép „egybeeshet”, vagyis a Java futtató kö rnyezet és a webszerver nyugodtan telepí thető arra a számító gépre, ahonnan a bö ngésző t elindítjuk. Legyen most a szerver és a kliens számító gép ugyanaz a számító gép; tanulásra és tesztelésre ez most nekünk megfelel! 1.5 ábra JSP futtatási kö rnyezet Az 1.5 ábra egy JSP futtatási kö rnyezetet ábrázol A kliens gépen van a bö ngésző , ahova beí rjuk a JSP lapot azonosí tó URL-t: most ez éppen a http://sdp-city:8080/minta/hurra.jsp Ezt a kérést a Tomcat webszerver fogadja, mert ö vé a 8080-as kapu. A Tomcat használja a

J2SE API-ját (a JSP szkriptben a println metó dus például a java.io-ban található ) 18 2. Javás webalkalmazások futtatása 2. Javá s webalkalmazá sok futtatá sa Ebben a fejezetben ö sszeállí tunk egy futtató kö rnyezetet, amelyen aztán külö nféle – egyszerűbb és bonyolultabb – JSP és szervlet alkalmazásokat fogunk futtatni. A programokat egyelő re csak használjuk; fejlesztő i szempontbó l még csak „ízlelgetjük” ő ket. A fogalmak tisztázása késő bb kö nnyebb lesz, ha konkrét példákhoz tudjuk kö tni azokat. 2.1 A Tomcat webszerver telepítése A webszervert általában egy szerver gépre szokás telepíteni, szolgáltatásait pedig valamely távoli, kliens géprő l szokás igénybe venni. Nekünk azonban egyelő re – a tanulás/fejlesztés idejében – tö kéletesen megfelel, ha a szerver és a kliens gép ugyanaz. A szerver programot tehát a saját gépünkre fogjuk telepí teni, s majd a bö ngésző t is innen indítjuk

el. Mi most Java alapú webszervert fogunk használni, amely műkö déséhez szükség van a Java kö rnyezetre. Ha a jö vő ben csak futtatni szeretnénk JSP programokat, akkor elegendő lenne csupán a futtató kö rnyezet (a JRE), de mi fejleszteni is akarunk majd, ezért használjuk inkább a fejlesztő kö rnyezetet, a J2SE-t! Mielő tt tehát telepítenénk a Tomcat webszervert, nézzük meg, van-e a gépen Java fejlesztő kö rnyezet, és ha nincs, telepítsük! Az Apache Tomcat telepí tő csomagja letö lthető a http://tomcat.apacheorg oldalró l A 41-es verzió telepí tő állományának neve például jakarta-tomcat-4.131exe Indítsuk el a telepí tő állományt, és telepí tsük fel gépünkre a szervert! A telepítő mielő tt megkezdené az érdemi munkát, beazonosí tja a Java kö rnyezetet a JAVA HOME alapján. Ü gyelni kell tehát e kö rnyezeti változó helyes beállí tására. Ezután a Tomcat kö nnyűszerrel feltelepül a kö vetkező lépésekben: 19

2. Javás webalkalmazások futtatása Látható , hogy a telepí téshez mintegy 33 MB-nyi helyre van szükség a merevlemezen. A telepí tés utolsó lépésként meg kell adnunk a szervert azonosító kaput (portot), valamint az adminisztrátor felhasználó i nevét és jelszavát – ezekkel az adatokkal lehet késő bb a szerverhez hozzáférni: Alapbeállí tások (Basic settings): − Http Connector Port (Http csatlakozó kapu): az alapértelmezett port. A szerver ezen a kapun fogadja a Http kéréseket. Alapértelmezés: 8080 − User name (felhasználó i név): Az adminisztrátor felhasználó i neve. Alapértelmezés: admin − Password (jelszó ): Az adminisztrátor jelszava. Alapértelmezés: (semmi) Az adminisztrátori név és jelszó megváltoztatása a tanulás idő szakában nem ajánlatos. Ha ugyanis megváltoztatja, majd elfelejti, a továbbiakban nem tud semmilyen mó don hozzáférni a szerverhez. Egyelő re nincs is mit „elrejtenünk” A TOMCAT HOME a

telepí tett Tomcat localhost-hoz rendelt alapkö nyvtára. Ha a szervert alapértelmezés szerint, a C:/ lemezegységre telepítettük, akkor TOMCAT HOME=C:/Program Files/Apache Group/Tomcat 4.1 Telepí tés után a TOMCAT HOME kö rnyezeti változó automatikusan értéket kap. A továbbiakban a TOMCAT HOME mindig a Tomcat alapkö nyvtárát jelenti ebben a kö nyvben is 20 2. Javás webalkalmazások futtatása Telepí tés után a programok menüjében, az Apache Tomcat 4.1 programcsoport alatt a kö vetkező programok jelennek meg: − Start Tomcat: A szerver elindí tása. Lásd késő bb − Stop Tomcat: A szerver leállí tása. Lásd késő bb − Tomcat 4.1 Program Directory: Belépés a TOMCAT HOME kö nyvtárba A kö nyvtár felépí tését lásd késő bb. − Tomcat Administration: A webszerver adminisztráció s felülete. A bö ngésző címsorában megjelenik a http://127.001/admin S mivel a localhoston a webalkalmazások alapértelmezett helye a domén gyö

kérkö nyvtárának webapps alkö nyvtára, ezért a helyi gépen megjelenik a %TOMCAT HOME/%webapps/admin.xml állomány Győ ző djö n meg ró la, hogy ez az állomány tényleg ott van-e! Vigyázat: a szolgáltatás csak akkor érhető el, ha elő ző leg a webszervert elindítottuk! Ha sikerült elindítani az adminisztráció s felületet, akkor jelentkezzen be azzal a felhasználó i névvel (User Name) és jelszó val (Password), amelyet installáláskor megadott! A megjelenő adminisztrátori felület lehető séget ad a teljes jogot élvező adminisztrátornak arra, hogy megtekintse, vagy akár mó dosítsa a webszervert elérő felhasználó k adatait, a szerver erő forrásait, beállításait stb. A Tomcat Administration egy JSP-ben megí rt alkalmazás, érdemes tanulmányozni! − Tomcat Documentation: Ez a Tomcat súgó ja. Ha a Tomcat telepítésekor kértük a Documentation and Examples telepítését is, akkor az a %TOMCAT HOME%/ webapps/tomcat-docs kö nyvtárban

található . A dokumentáció online mó don is elérhető a Tomcat honlapjáró l. − Tomcat Home Page: Ugrás a Tomcat honlapjára: http://tomcat.apacheorg − Uninstall Tomcat 4.1: A telepí tett Tomcat leszedése a szerver géprő l 2.2 A webszerver elindítá sa, leá llítá sa A bö ngésző csak akkor tud kommunikálni a szerverrel (csak akkor képes például megjelení teni egy JSP lapot), ha a háttérben fut a webszerver. A szolgáltató k webszerverei 21 2. Javás webalkalmazások futtatása állandó an futnak. Saját gépünkö n azonban használat után nyugodtan leállíthatjuk a szolgáltatást, hogy az ne terhelje feleslegesen gépünket. A szervert a kö vetkező képpen indí thatjuk el: Start/Apache Tomcat 4.1/Start Tomcat, vagy a szolgáltatásokat tartalmazó bin kö nyvtárban levő startup.bat futtatásával Leállí tani majd í gy fogjuk: Start/Apache Tomcat 4.1/Stop Tomcat, vagy a szolgáltatásokat tartalmazó bin kö nyvtárba levő shutdown.bat

futtatásával ☼ É rdeklő dő knek Mindkét esetben a %TOMCAT HOME%/bin/bootstrap.jar futtatható JAR állományt futtatjuk – start, illetve stop paraméterekkel. Errő l meggyő ző dhetünk, ha megtekintjük a Start Tomcat, illetve Stop Tomcat tulajdonságában a végrehajtandó parancsot. A Tomcat elindítására megjelenik egy konzolos ablak, amely a szerver futása alatt mindvégig nyitva van: Elő fordulhat, hogy a webszerver induláskor rengeteg kivételt dob. Ez akkor fordul elő , ha a a szerver a webapps kö nyvtárban található alkalmazásokban szintaktikai hibát talál. Indításkor ugyanis a Tomcat a webapps kö nyvtárban levő war (Web ARchive) állományokat kibontja, és mindent lefordí t, ami még nincs lefordítva. Tanácsok: − ha a bö ngésző nem látja a localhostot, akkor a bö ngésző ben a helyi háló zat proxybeállí tását kapcsolja ki: Eszkö zö k/Internetbeállítások/Kapcsolatok/LAN/proxy − Ha nem frissül a bö ngésző ben a lap,

akkor frissítés (az erő forrás erő szakos újratö ltése) segí thet: Ctrl-F5. 22 2. Javás webalkalmazások futtatása 2.3 A webszerver mapparendszere Kapcsoljon le a telepí tés célhelyére: Start/Apache Tomcat 4.1/Tomcat 41 Program Directory A helyi gépen ezzel belépünk a TOMCAT HOME kö nyvtárba. A kö vetkező kö nyvtárszerkezet tárul elénk: Nézzük meg nagy vonalakban, mit rejtenek ezek a mappák: − bin: Itt vannak a szerver elindí tásához és leállításához szükséges szolgáltatások: jar és batch állományok. Ebben a mappában van tö bbek kö zö tt a startup és a shutdown parancs (kiterjesztésük windowsban bat, linuxban sh). − common: Az alkalmazások kö zö s API gyűjteménye. Java Archive (JAR) osztálykö nyvtárak, például mailjar, servletjar stb − conf: A szerver konfiguráció s állományai, például a server.xml állomány Itt található k a minden webalkalmazásra érvényes beállítások. − logs: Napló fájlok.

Ide kerülnek bejegyzésre a szerverrel kapcsolatos fontosabb tö rténések, mint indí tás, leállí tás stb. − server: − shared: − temp: − webapps: A szerver által felügyelt alkalmazások, programok alapértelmezett kö nyvtára. A webapps kö nyvtárban vannak a webalkalmazások – minden webalkalmazás egy külö n kö nyvtárban. − work: 2.4 A webalkalmazá s felépítése Egy webalkalmazás bö ngésző bő l futtatható , van egy kezdő lapja, ahonnan további lapok érhető k el. A lapok tö bbsége dinamikus, hiszen ettő l alkalmazás A webalkalmazást és annak saját erő forrásait tipikusan egy – az alkalmazás nevét viselő – mappa tartalmazza. A Tomcat webszerveren a helyi alkalmazások a webapps kö nyvtárban található k – minden alkalmazás egy külö n kö nyvtárban. 23 2. Javás webalkalmazások futtatása Az alkalmazás JSP lapjai az alkalmazás kö nyvtárában bárhol elhelyezhető k, kivéve a WEBINF kö nyvtárat, ahol a lapok

mö gö tti alkalmazási logika „lapul”. Ezt a Java osztályokat tároló kö nyvtárat egyetlen kliens sem láthatja. A WEB-INF kö nyvtár felépítése bizonyos szempontbó l hasonló egy asztali alkalmazás projektkö nyvtárának felépítéséhez: a classes kö nyvtárban található k például a lefordí tott bájtkó dok, amely mapparendszere megfelel a csomagfelépítés szabályainak. Elvileg tehetjük ide az src kö nyvtárat is, de figyelembe kell venni, hogy a webapps tipikusan futtatási kö nyvtár. Az alkalmazá s kö nyvtá rszerkezete A kö vetkező struktúra egy tipikus webalkalmazás mapparendszerét mutatja. Az alkalmazás kö nyvtára a webapps/[alkalmazásnév], a vastagon szedett azonosító k kö nyvtárnevek: index.html jsp *.jsp images *.jpg WEB-INF web.xml lib *.jar classes *.class tlds *.tld Az alkalmazás kö nyvtárának egyetlen kö telező alkö nyvtára van, a WEB-INF, s annak egyetlen kö telező állománya, a web.xml (az alkalmazás

telepítésleíró ja) A WEB-INF kö nyvtárat csak a szerver látja, a kliensek nem látják – ide kell elhelyezni minden olyan információ t, amit nem akarunk kitenni a nagykö zö nség számára. A JSP lapok és más állományok a WEB-INF kö nyvtáron kívül helyezendő k el, ezek szerkezete nem kö tö tt. Nézzük sorra az alkalmazás ajánlott kö nyvtárait: − jsp: Ha az alkalmazásnak sok JSP lapja van, akkor ebben a kö nyvtárban szokás elhelyezni azokat. Néhány JSP lapot nyugodtan be lehet tenni az alkalmazás fő kö nyvtárába. A JSP lapok alkö nyvtárakba szervezhető k A JSP lapok egymásró l érhető k el, és általában van egy fő lap, ami jellemző en az index.html vagy indexjsp Az egyes lapok elvileg külö n kérésre is elérhető k. − images: Itt szokás elhelyezni az alkalmazás képállományait. − WEB-INF: Ebben a kö nyvtárban vannak a futtatható Java osztályok és az ehhez szükséges leí ró k. A webxml állomány az alkalmazás

telepítésleíró ja (lásd lent) − lib: Itt található k az alkalmazás által használt osztálykö nyvtárak. Az alkalmazás ezeken kí vül még használhatja az ö sszes webalkalmazás kö zö s kö nyvtárát (webapps/common) is. − classes: Ez az alkalmazás „motorja”, itt vannak a programok: szervletek, babok és más, normál Java osztályok 24 2. Javás webalkalmazások futtatása − tlds: A JSP lapokró l ún. akció kat lehet indítani, amelyeket Java osztályok hajtanak végre. Itt kell elhelyezni az alkalmazás akció inak leíró állományait Telepítésleíró Az alkalmazásnak tartalmaznia kell egy telepí tésleíró t