Preview špecifikácie Java Servlet 2.4

1. srpna 2003

•

Posledná „Proposed Final Draft“ špecifikácia, vydaná firmou SUN Microsystems v spolupráci s expertnou skupinou JSR 154 (Java Specification Request), je verzia PFD3 z 10. apríla 2003. Táto špecifikácia samozrejme nie je konečná, ale zmeny budú skôr kozmetického charakteru. Servlety 2.4 budú integrálnou súčasťou pripravovanej špecifikácie J2EE 1.4,ktorá je momentálne vo verzii beta 2.

V rôznych zdrojoch na internete sa môžete dočítať, že nová špecifikácia neprináša žiadne prevratné zmeny, skôr len jemné doladenia existujúcich charakteristík. V podstate je to pravda. Napriek tomu boli pridané nové prvky a vylepšenia existujúcich. Ide hlavne o tieto oblasti:

ServletRequest – nové metódy a nové možnosti listenerov.
RequestDispatcher – nová funkčnosť.
HttpSession – ďalšie možnosti práce so session.
Zmeny v oblasti internacionalizácie.
SingleThreadModel – je odteraz deprecated.
Špecifikácia 2.4 už vyžaduje HTTP 1.1, J2SE 1.3.
Konfiguračný súbor web.xml bude definovaný cez XML schému, bude obsahovať nové elementy a niektoré pôvodné budú vyradené.
Ako welcome súbor už môžete použiť aj servlet.

ServletRequest

Rozhranie ServletRequest a trieda ServletRequestWrapper teraz obsahuje štyri nové metódy:

getRemotePort(): vráti IP port klienta alebo posledného proxy, z ktorého prišla požiadavka na servlet. Doplňuje existujúce metódy getRemoteAddr() a getRemoteHost().
getLocalName(): vráti host name servera, ktorý obdržal požiadavku.
getLocalAddr(): vráti IP adresu servera, ktorý obdržal požiadavku.
getLocalPort(): vráti číslo portu servera, na ktorom obdržal požiadavku.

Tieto metódy umožňujú preveriť detaily IP pripojenia jednak zo strany klienta (remote) a jednak zo strany servera (local).

K existujúcim listenerom, pracujúcim nad kontextom a správou session webovej aplikácie, pribudli ďalšie, pracujúce s klientskými požiadavkami. Konkrétne ide o rozhrania ServletRequestListener, ServletRequestEvent, ServletRequestAttributeListener a ServletRequestAttributeEvent. Podľa všetkého nájdu najväčšie využitie v etape vývoja a testovania servletov.

RequestDispatcher

V podstate toto rozhranie umožňuje vytvoriť objekt, ktorý môže obdržať požiadavku od klienta (objekt HttpServletRequest) a predať ju inému zdroju (napríklad servletu, stránke JSP alebo HTML). Servlet kontajner použije objekt RequestDispatcher ako „obal“ okolo tohto zdroja definovaného pomocou cesty alebo mena. Toto rozhranie obsahuje veľmi dôležité metódy forward() a include(). V princípe prvá metóda umožňuje presunúť požiadavku na iný zdroj a druhá metóda prevezme výsledok činnosti z externého zdroja.

V doterajšej špecifikácii 2.3 pri volaní metódy forward() nebolo možné zistiť originálne URI (t.j. URI servletu, z ktorého bola metóda forward() zavolaná) z „forwardovaného“ servletu. Externý zdroj teda nemal prístup k tejto hodnote, respektíve bola servlet kontajnerom zmenená. V novej špecifikácii tak môžete použiť getAttribute(javax.servlet.forward.request_uri) (prostredníctvom metódy objektu HttpServletRequest). Okrem tohto parametra boli pridané ešte štyri ďalšie:

javax.servlet.forward.context_path
javax.servlet.forward.servlet_path
javax.servlet.forward.path_info
javax.servlet.forward.query_string

Dúfam, že význam týchto parametrov dostatočne vyplýva z ich názvu. Ostatné metódy getRequestURI(), getContextPath(), getServletPath(), getPathInfo() a getQueryString() zostávajú v platnosti, ale vždy sa týkajú cieľového servletu alebo iného zdroja. Ak potrebujete vedieť originálne (pôvodné) URI, použite horeuvedené parametre.

Ďalšia zmena sa týka spolupráce s filtrami. (Filtre sú v podstate komponenty, ktoré môžu modifikovať obsah prichádzajúcej požiadavky, hlavičky http a vytvorenej odpovede. Teda nevytvárajú ani request ani response iba ho modifikujú.) Vo verzii 2.3 nebolo určené, či a ako majú filtre pracovať pri presmerovaných alebo vkladaných požiadavkách. V novej verzii pribudol nový element aplikačného deskriptora web.xml nazvaný <dispatcher>. Môže obsahovať hodnoty REQUEST, FORWARD, INCLUDE, ERROR. Príklad:

<filter-mapping>
  <filter-name>Filter</filter-name>
  <url-pattern>/filtered/*</url-pattern>
  <dispatcher>REQUEST</dispatcher>
  <dispatcher>INCLUDE</dispatcher>
</filter-mapping>

Tento príklad hovorí, že Filter bude použitý na všetky požiadavky prichádzajúce priamo od klienta a na všetky ostatné vzniknuté volaním metódy include(). A samozrejme musí byť splnená aj požiadavka na cestu /filtered/*. Môžete použiť ktorúkoľvek hodnotu v ľubovolnom poradí. Hodnota FORWARD sa týka presmerovaných požiadaviek a hodnota ERROR požiadaviek spracovávaných mechanizmom <error-page>. Ak neuvediete žiadnu hodnotu, použije sa REQUEST.

HttpSession

V predchádzajúcom draftu PFD2 bola navrhnutá nová statická metóda logout(). Jej úlohou bolo odhlásiť klienta z aktuálneho sedenia. Prišlo sa však na to, že táto metóda má zmysel len v prípade, že klient bol prihlásený mechanizmom FORM. Teda prostredníctvom klasického HTML formulára. V ostatných typoch autentifikačných schém BASIC, DIGEST a CLIENT-CERT nemal servlet kontajner praktickú možnosť zabrániť klientovi v ďalšiemu posielaniu autentifikačných údajov. Preto bola táto metóda z PFD3 odstránená.

Znakové sady a locale

Zmena nastala v rozhraní ServletResponse a ServletResponseWrapper. Pribudli tam metódy setCharacterEncoding() a getContentType(). Prostredníctvom prvej môžete nastaviť spôsob kódovania znakov v odpovedi na požiadavku. Toto je myslím už tretí možný spôsob, ako to spraviť (+ setLocale() a setContentType()). Metóda getContentType() vráti MIME typ odpovede. Okrem týchto zmien pribudla aj možnosť mapovať jednotlivé typy locale na jednotlivé typy znakových sád. A to prostredníctvom zmeny v deskriptore webovej aplikácie web.xml, kde pribudol element <locale-encoding-mapping-list>. Príklad:

<locale-encoding-mapping-list>
  <locale-encoding-mapping>
    <locale>sk</locale>
    <encoding>ISO-8859-2</encoding>
  </locale-encoding-mapping>
</locale-encoding-mapping-list>

SingleThreadModel

Ako som už uviedol, toto rozhranie je od teraz deprecated. Teda neodporúča sa jeho použitie a kompilátor vás na to patrične upozorní. Je vysoko pravdepodobné, že v nasledujúcej verzii bude tento model úplne odstránený.

Špecifikácia 2.4 už vyžaduje HTTP 1.1 a J2SE 1.3

Podľa novej špecifikácie musí servlet kontajner podporovať HTTP 1.1 a J2SE 1.3. To znamená, že servlety verzie 2.4 sú závislé na novšej verzii http protokolu. Táto zmena prináša tiež novú konštantu HttpServletResponse.SC_FOUND, predstavujúcu stavový kód 302 HTTP 1.1 protokolu. Táto konštanta zodpovedá konštante SC_MOVED_TEMPORARILY pre protokol HTTP 1.0. Obidve konštanty zotrvávajú v platnosti, preferovaná je však prvá.

Treba poznamenať, že nie všetky servery novší protokol podporujú. Rovnako ak si chcete vyskúšať nové vlastnosti servletov, nemusíte hneď vlastniť veľký komerčný aplikačný server. Môžete si stiahnuť a nainštalovať referenčnú implementáciu Java Servlet 2.4 špecifikácie Jakarta Tomcat 5.0.5 (momentálne vo verzii alfa z 25. júla 2003).

Zmeny v deskriptore web.xml

Mnohé zo zmien sme už spomenuli, prevažne išlo o zavedenie nových elementov. Podstatnejšou zmenou je, že web.xml od verzie 2.4 bude založený na XML schéme XSD konzorcia W3C. Táto zmena spôsobí, že elementy vnorené vo <web-app> nemusia dodržiavať presne stanovené poradie výskytu. Zmenou je, že element <role-name> je unikátny, môže sa vyskytovať iba raz, na rozdiel od <distributable/>, ktorý sa môže vyskytovať viackrát. Ďalej boli z deskriptora vyňaté elementy sprístupňujúce niektoré J2EE komponenty: <env-entry>, <ejb-ref>, <ejb-local-ref>, <resource-ref> a <resource-env-ref>.