• descrierea funcționalității pe care o pune la dispoziție tehnologia JavaServer Pages și a avantajelor pe care le oferă în comparație cu alte tehnologii similare;
• înţelegerea mecanismului prin care este generat răspunsul la o cerere pentru o pagină Internet solicitată din browser, în cazul folosirii de pagini JSP;
• integrarea unei aplicații web ce folosește Java Servlets / JavaServer Pages în contextul serverului Apache Tomcat;
• implementarea operațiilor corespunzătoare ciclului de viață a unei pagini JSP;
• proiectarea unei aplicații web ce folosește Java Servlets / JavaServer Pages potrivit modelului arhitectural adecvat specificațiilor funcționale;
• folosirea elementelor componente din structura unei pagini JSP (directive, acțiuni, scripleți, expresii, declarații, obiecte implicite) pentru implementarea unor aspecte de logica aplicației ce nu pot fi delegate către Java Servlets;
• utilizarea unor biblioteci de etichete (predefinite - JSTL sau definite de utilizator) / API-uri (JavaMail / Java Activation Framework) / EL (Expression Language) pentru dezvoltarea unor funcționalități complexe;

JavaServer Pages, web application, html, xml, svg, wml, markup, Java Beans, Apache Tomcat 8.x, JSP life cycle, parse exception, jasper exception, client-server model, N-tier model, model-view-controller, directive, action, scriplet, expression, declaration, implicit objects, cookie, session, filter, file upload, resource invocation, email managing, expression language, instant evaluation, lazy evaluation, JavaServer Faces, JSTL, custom tags

aipi2014-lab08-slides.pdf

aipi2014-lab08-slides-3pp.pdf

JavaServer Pages este o tehnologie pentru realizarea de aplicații Internet generate dinamic şi bazate pe HTML, XML sau alte tipuri de documente. A fost lansată pe piaţă de compania Sun Microsystems în anul 1999 ca răspuns la tehnologiile PHP şi ASP, demonstrând faptul că Java este un limbaj de programare suficient de robust pentru a răspunde la provocările web-ului.

Tehnologia JavaServer Pages e parte integrantă Java Enterprise Edition implementând de regulă intefaţa cu utilizatorul dintr-o aplicaţie web Java.

O pagină JSP este un document text care cuprinde două tipuri de date: statice care pot fi descrise în orice format (HTML, XML, SVG, WML) – denumite şi elemente de adnotare (eng. markup) şi dinamice, care pot fi directive JSP şi scripleţi, adică blocuri de cod sursă Java (de obicei cuprinse între adnotările <% şi %>) folosite pentru implementarea unor funcţionalităţi complexe, cum ar fi, de exemplu, comunicaţia cu o bază de date, reţinerea preferinţelor utilizatorilor, accesarea componentelor Java Beans, transferul controlului între pagini şi partajarea informaţiei între cereri, răspunsuri şi pagini.

Funcţionalitatea pe care o pune la dispoziţie tehnologia JSP este aceeaşi cu a aplicaţiilor implementate folosind CGI (Common Gateway Interface), distingându-se de acestea prin performanţă îmbunătăţită (posibilitatea integrării de elemente dinamice în pagina HTML în loc să se folosească fişiere separate), compilarea înainte de plasarea în contextul serverului, posibilitatea accesării tuturor funcţionalităţilor oferite de interfeţele de programare Java (JDBC, JNDI, JAXP, EJB), utilizarea unui model care implică delegarea logicii aplicaţiei către Java Servlets.

Avantajele utilizării JavaServer Pages includ:

• separarea logicii aplicaţiei de prezentare (întreţinerea este mai uşoară atât din partea programatorilor, cât şi a dezvoltatorilor web); logica aplicaţiei este folosită pentru a genera conţinutul dinamic şi poate fi realizată prin componente Java Beans, în timp ce interfaţa cu utilizatorul este formată prin etichete JSP;
• portabilitate (asigurată de limbajul de programare Java – aplicaţia web poate fi utilizată pe mai multe platforme cu arhitectură diferită fără a fi necesară modificarea lor);
• conţinutul dinamic care poate fi generat;
• se bazează pe tehnologia Java Servlets, astfel încât preia şi avantajele pe care le oferă aceasta; tehnologia JavaServer Pages reprezintă o abstractizare de nivel înalt a Java Servlets; totodată, în pagina JSP poate fi reutilizat codul care a fost dezvoltat într-un Java Servlet.

Deşi din punctul de vedere al programatorului un Java Servlet reprezintă o clasă Java (unde generarea elementelor de adnotare se face prin apelarea unor metode) iar o pagină JSP se aseamănă mai mult cu un document (unde conţinutul static este separat de conţinutul dinamic – generat de componente Java Beans sau etichete JSP), tehnologiile sunt echivalente. O pagină JSP este transformată într-un Java Servlet (care este compilat) responsabil de comunicaţia cu clientul şi de toate celelalte prelucrări. Modificările realizate asupra unei pagini JSP sunt detectate în mod automat, astfel încât atât procesul de transformare într-un Java Servlet cât şi procesul de compilare corespunzător sunt reluate atunci când se face o cerere pentru aceasta.

Atunci când 1) un client transmite (din browser) o cerere HTTP către server pentru o pagină .jsp, 2) aceasta este transmisă mai departe motorului JSP care încarcă de pe disc resursa care a fost indicată prin intermediul URL-ului. Dacă pe server nu există un Java Servlet corespunzător celei mai recente versiuni a paginii respective, 3) acesta este generat (prin instrucţiuni de tip println ce includ etichetele respective şi convertirea elementelor JSP în cod Java care implementează comportamentul dinamic al paginii) şi 4) apoi compilat într-o clasă executabilă. Acest cod, căruia i se pasează cererea originală 5) este rulat de motorul Java Servlet producând un rezultat în format HTML care este transmis serverului ca răspuns HTTP, acesta 6) fiind pasat clientului care îl afişază în browser, ca şi când ar fi conţinut static.

În cazul unei aplicaţii web folosind tehnologia JSP, aceasta va fi plasată în directorul webapps.

Paginile .jsp se vor găsi în rădăcina directorului unde a fost dezvoltată aplicaţia web. Pagina care va fi afişată automat atunci când se solicită adresa: http://<server_IP>:<server_port>/<application_directory>/ este index.jsp sau cea precizată prin elementul <welcome-file> din secţiunea <welcome-file-list> a fişierului de configurare web.xml. Acesta va fi plasat în directorul WEB-INF, specificându-se diferiţi parametrii ai aplicaţiei web (inclusiv despre clasele Java Servlet ce implementează logica aplicaţiei). De asemenea, în condiţiile în care sunt folosite metode din clase Java, acestea vor fi plasate într-un director WEB-INF/classes. Este recomandat ca acestea să fie modularizate pe pachete pentru ca referirea lor să se poată realiza cu uşurinţă. Dacă se folosesc biblioteci speciale (în arhive .jar), acestea trebuie incluse în WEB-INF/lib. Astfel de biblioteci speciale pot fi “driver”-ul de conectare la baza de date precum şi biblioteca pentru accesarea funcţionalităţilor oferite de JSTL (JavaServer Pages Standard Tag Library). Deşi sursele aplicaţiei se pot găsi în orice fişier, este recomandat ca acestea să se găsească tot aici, într-un subdirector denumit src sau sources, astfel încât să poată fi identificat cu uşurinţă, iar procesul de compilare al surselor şi de transfer al claselor (realizat înainte de operaţia de configurare – eng. deploy a aplicaţiei web) să nu implice un efort deosebit.

Încărcarea tuturor acestor clase se face atunci când este pornit serverul:

Dec 4, 2014 12:00:00 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory ApacheTomcat\apache-tomcat-8.0.15\webapps\BookStore

Spre diferenţă de Java Servlets, nu este necesară realizarea configurării aplicaţiei web atunci când sunt realizate modificări asupra paginilor JSP, întrucât acestea sunt detectate automat, determinând generarea unor Java Servlets corespunzătoare atunci când paginile sunt accesate de către client. Repornirea serverului Apache Tomcat va fi necesară doar în cazul operării unor modificări pentru clasele Java ce sunt utilizate de aplicaţie, fiind necesară reîncărcarea lor (după ce compilarea lor este realizată de către programator).

Clasele Java Servlet generate pentru fiecare aplicaţie pot fi vizualizate în %CATALINA_HOME%\work\Catalina\<server_IP>\<application_directory>\org\apache\jsp.

Corespondentul unei pagini page.jsp va fi un Java Servlet page_jsp.java. Tot aici vor fi plasate şi clasele obţinute prin compilarea acestor Java Servlets. Atât operaţia de transformare din pagină JSP în Java Servlet cât şi compilarea claselor Java Servlet generate este realizată automat de către serverul Apache Tomcat.

Datorită faptului că o cerere pentru o pagină JSP implică (în unele situaţii) transformarea într-un Java Servlet precum şi compilarea acestuia, vizualizarea acesteia se va face după o perioadă mai mare decât în situaţia când aceste prelucrări nu mai trebuie realizate. De asemenea, trebuie avută în vedere situaţia în care o astfel de operaţie eşuează, astfel încât în browser sunt afişate excepţiile generate în loc de conţinutul paginii solicitate.

Versiunea Apache Tomcat 8.0.15 suportă specificaţia JSP 2.3 şi EL 3.0.

O pagină JSP tratează cererile asemenea unui servlet. Acesta este motivul pentru care ciclul de viaţă (ca de altfel şi multe alte capabilităţi) al paginilor JSP (în special aspectele dinamice) este asemănător cu cel al tehnologiei Java Servlet.

În plus faţă de etapele caracteristice Java Servlets (creare, iniţializare, gestiune cereri şi răspunsuri, distrugere), mai există şi etapa de compilare. Atunci când o cerere este asociată unei pagini JSP, aceasta este tratată de un servlet special care verifică dacă servlet-ul asociat paginii JSP este mai vechi decât pagina în cauză, situaţie în care îl generează şi îl compilează. Astfel, un avantaj pe care îl au paginile JSP faţă de Java Servlets este că procesul de compilare este realizat automat.

Odată ce pagina JSP a fost transformată şi compilată, servlet-ul corespunzător va urma ciclul de viaţă corespunzător (încărcarea claselor, instanţierea lor, apelul metodei init() pentru iniţializarea resurselor (partajate) şi încărcarea unor fişiere de configurare, execuţia (interacţiunea cu clientul şi realizarea procesărilor prin metoda service()), precum şi apelul metodei destroy() dacă servlet-ul nu mai este necesar). Metodele (generate) se vor numi, în acest caz, _jspInit(), _jspService(), _jspDestroy(). Metodele jspInit() şi jspDestroy() (apelate o singură dată în ciclul de viaţă al unei pagini JSP) pot fi suprascrise ca declaraţii JSP (cuprinse între <%! şi %>). Nu se recomandă însă suprascrierea metodei _jspService() întrucât aceasta este generată în mod automat prin transformarea elementelor JSP în codul Java corespunzător, respectiv prin apelul metodei println() (a obiectului PrintWriter asociat) pentru generarea etichetelor.

public void _jspInit() {
    // ...
}
 
public void _jspDestroy() {
    // ...
}
 
public void _jspService (final javax.servlet.http.HttpServletRequest request, final javax.servlet.http.HttpServletResponse response) throws java.io.IOException, javax.servlet.ServletException {
    // ...
}

Toate aceste metode fac parte din interfaţa javax.servlet.HttpJspPage.

În cadrul procesului de compilare, motorul JSP verifică dacă este necesar să compileze pagina respectivă (în situaţia în care aceasta nu a fost niciodată compilată, sau eticheta de timp a servlet-ului corespunzător nu corespunde celei mai recente modificări), acestă operaţie fiind precedată de transformarea paginii, ce include şi parsarea acesteia.

Atât procesul de transformare şi cât şi procesul de compilare pot genera erori care sunt scoase în evidenţă doar atunci când pagina este accesată pentru prima dată:

• dacă eroarea apare în timpul transformării, serverul va întoarce excepţia ParseException iar clasa servlet va fi incompletă, astfel că ultima linie incompletă va fi un indicator către elementul JSP incorect;
• dacă eroarea se produce atunci când pagina JSP este compilată (dacă avem o eroare de sintaxă în scriptlet), serverul va întoarce excepţia JasperException precum şi un mesaj care include numele servlet-ului asociat paginii JSP şi linia la care s-a constatat eroarea.

Atunci când se execută o pagină JSP pot apărea excepţii, acestea trebuind tratate separat, în cadrul unei pagini dedicate unei astfel de acţiuni:

<%@ page errorPage="errorpage.jsp" %>

Pentru ca excepţia (într-un obiect de tip javax.servlet.jsp.JspException) să fie disponibilă în cadrul paginii de eroare pentru a o trata, trebuie specificată, la începutul paginii de eroare, directiva:

<%@ page isErrorPage="true|false" %>

În etapa de iniţializare, care se execută o singură dată (după crearea servletului asociat paginii JSP), este apelată metoda _jspInit() unde se realizează conexiunea la baza de date, sunt încărcate diferite resurse şi se fac alte operaţii ce ţin de configurarea aplicaţiei web. În general, aici sunt iniţializate obiectele pentru accesarea funcţionalităţilor puse la dispoziţie de diferite biblioteci (frecvent, Java Server Pages Standard Tag Library), însă programatorul are posibilitatea de a realiza propriile operaţii, prin suprascrierea metodei jspInit() care va fi inclusă în cadrul acestei funcţii.

Etapa de execuţie constă în generarea unui răspuns pentru fiecare cerere prin apelul metodei _jspService(). Aceasta va trata fiecare dintre metodele HTTP prin care clientul comunică cu serverul (GET, POST, PUT, DELETE, OPTIONS, TRACE).

În etapa de distrugere, corespunzătoare procesului de înlăturare a paginii JSP din container, este apelată metoda _jspDestroy() unde sunt eliberate resursele utilizate de aplicaţie, astfel încât acestea să fie procesate de modulul de gestiune a memoriei. În situaţia în care se doreşte eliberarea manuală a acelor resurse care au fost iniţializate (conexiunea la baza de date, diverse fişiere de configurare), poate fi suprascrisă metoda jspDestroy(), conţinutul ei fiind copiat în cuprinsul funcţiei generate.

Combinarea de cod Java cu etichete HTML oferă posibilitatea realizării de pagini cu conţinut dinamic, însă în cazul aplicaţiilor cu funcţionalitate complexă, procesul de întreţinere poate fi dificil, problema provenind în special din faptul că partea de logică a aplicaţiei (care este dezvoltată de programatori – implicând algoritmi şi interacţiune cu baza de date) nu este separată de partea de prezentare (realizată de regulă de dezvoltatori web – concentrându-se mai ales pe elemente de grafică). Arhitectura aplicaţiei JSP va reflecta raportul dintre aceste aspecte.

În modelul 1, logica aplicaţiei este implementată în clase Java (componente Java Beans) şi poate fi apelată din partea de prezentare realizată prin pagini JSP. Această soluţie este adecvată pentru cazul în care aplicaţia nu este foarte complexă, o problemă fiind constituită de faptul că toată comunicaţia cu clientul trebuie realizată din pagina JSP. O astfel de abordare se mai numeşte client-server, are avantajul simplităţii şi dezavantajul lipsei de scalabilitate.

În modelul 2 (denumit şi abordare pe N-niveluri datorită separării arhitecturii serverului pe mai multe niveluri), se respectă şablonul de proiectare Model View Controller unde servlet-ul se ocupă de cererea de la client, implementează logica aplicaţiei, realizând totodată şi instanţierea componentelor Java Beans. Pagina JSP obţine date de la componentele Java Beans şi transmite un răspuns către client, prelucrările fiind realizate în mod transparent. Acest tip de abordare e adoptat atunci când aplicaţia este mai complexă, caracterizându-se prin uşurinţa de întreţinere şi eficienţă.

Aşadar, în cadrul unei pagini JSP se utilizează o combinaţie între etichete HTML (sau XML) şi blocuri de cod sursă Java pentru generarea de elemente dinamice. Fiecare pagină JSP este compilată într-un servlet, acesta primind cererea şi transmiţând mai departe răspunsul.

O pagină JSP poate conţine etichete de prezentare (în limbajul HTML), etichete JSP standard şi etichete definite de utilizator.

JSP foloseşte ca etichete standard:

• directive;
• acţiuni;
• scripleţi:
  • expresii;
  • declaraţii.

De asemenea, pot fi folosite comentarii care pot fi:

• comentarii JSP: acestea sunt ingorate de motorul JSP;

  <%-- comentariu; --%>

• comentarii HTML: acestea sunt ignorate de browser;

  <!-- comentariu -->

O directivă este o instrucţiune care indică informaţii generale despre pagina respectivă. Aceasta afectează întreaga structură a clasei servlet. Directiva oferă container-ului diverse informaţii cu privire la modul în care va gestiona anumite aspecte ale procesării paginii JSP.

<%@ directive attribute="value" %>

Directivele pot avea un număr variabil de perechi atribut-valoare, acestea fiind separate prin virgulă. Spaţiile dintre <%@ şi numele directivei, respectiv dintre ultima pereche atribut-valoare şi %> sunt opţionale. Există trei tipuri de directive:

• <%@ page ... %> – defineşte atribute specifice paginii JSP, cum ar fi limbajul de programare pentru scripturi, pagina corespunzătoare erorilor şi cerinţe legate de stocarea temporară;
• <%@ include ... %> – include un fişier în cadrul etapei de transformare a paginii JSP în servletul corespunzător;
• <%@ taglib ... %> – defineşte o bibliotecă de etichete, conţinând acţiuni definite de utilizator, care vor fi utilizate în cadrul paginii.

Directiva page este utilizată pentru a oferi containerului informaţii despre pagina JSP curentă. Cu toate că această directivă poate fi plasată oriunde în cadrul paginii, se recomandă ca ea să fie inclusă la început.

Sintaxa acestei directive poate lua următoarele forme:

<%@ page attribute="value" %>

<jsp:directive.page attribute="value" />

Atributele suportate de directiva page sunt:

<%@ page buffer="8kb" autoFlush="true" %>
<%@ page autoFlush="false" %>

<%@ page buffer="none" %>
<%@ page buffer="8kb" %>

<%@ page contentType="text/html" %>
<%@ page contentType="text/xml" %>
<%@ page contentType="application/msword" %>
<%@ page contentType="text/html:charset=ISO-8859-1" %>

<%@ page errorPage="errorpage.jsp"%>

<%@ page isErrorPage="false" %>
<%@ page isErrorPage="true" %>

<%@ page extends="myPackage.MyClass" %>

<%@ page import="java.sql.*, java.util.*, java.io.*" %>

<%@ page info="Some info on my JSP Page" %>

<%@ page isELIgnored="true" %>
<%@ page isELIgnored="false" %>

<%@ page isScriptingEnabled="true" %>
<%@ page isScriptingEnabled="false" %>

<%@ page isThreadSafe="true" %>
<%@ page isThreadSafe="false" %>

<%@ page language="java" %>
<%@ page language="javascript" %>

<%@ page session="true" %>
<%@ page session="false" %>

Directiva include este folosită pentru a include resursa specificată în fişierul curent, în cadrul etapei de transformare a paginii JSP în servlet. Practic, se concatenează conţinutul acestor fişiere externe, la locaţia unde a fost specificată (oriunde în pagina JSP):

<%@ include file="myJSPPage.jsp" %>

<jsp:directive.include file="myJSPPage.jsp" />

Se consideră că resursa specificată este indicată prin calea sa relativă, astfel încât atunci când ea lipseşte, se consideră că fişierul se găseşte în acelaşi director cu pagina JSP din care este invocat.

O astfel de funcţionalitate este folosită mai ales pentru includerea de resurse comune pentru toate paginile Internet cum ar fi: header, footer sau meniuri ale aplicaţiei web.

Directiva taglib permite definirea de către utilizator a unor etichete JSP care implementează o anumită funcţionalitate, acestea fiind grupate în cadrul unor biblioteci. Se specifică pentru fiecare set de etichete locaţia la care se află biblioteca respectivă (atributul uri), identificând un mecanism (atributul prefix) prin care acestea vor fi identificate în cadrul paginii JSP:

<%@ taglib uri="uri" prefix="prefixOfTag" %>

<jsp:directive.taglib uri="uri" prefix="prefixOfTag" />

Pot fi folosite biblioteci standard (care implementează controlul fluxului într-un program, care pun la dispoziţie mecanisme pentru gestiunea informaţiilor dintr-o bază de date sau care implementează diferite metode uzitate mai frecvent în cadrul oricărei aplicaţii) sau se pot crea biblioteci definite de utilizator:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ taglib prefix="sql" uri="http://java.sun.com/jsp/jstl/sql" %>
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>
<%@ taglib prefix="my" uri="http://www.mysite.com/mylibrary" %>

Utilizarea unei astfel de etichete se face cu <prefixName:tagName …> unde prefixName este valoarea specificată pentru atributul prefix de la definirea bibliotecii respective, iar tagName numele unei etichete implementate.

O acţiune este un marcaj care specifică comportamentul motorului Java Servlets de la nivelul serverului web, în momentul compilării marcajele fiind înlocuite cu codul sursă Java corespunzător acţiunii.

Sintaxa unei acţiuni este:

<jsp:actionName attribute="value" />

Atributele comune tututor tipurilor de acţiuni sunt:

• id: identifică în mod unic acţiunea respectivă permiţând ca aceasta să poată fi referită în cadrul paginii JSP; dacă acţiunea este folosită pentru crearea unei instanţe a unui obiect, prin intermediul identificatorului aceasta poate fi utilizată pe tot parcursul obiectului implicit PageContext;
• scope: defineşte ciclul de viaţă al acţiunii, adică vizibilitatea elementului concretizată în posibilitatea de utilizare a identificatorului acestuia; valorile pe care le poate sunt: page, request, session şi application.

O acţiune este de fapt o funcţie predefinită, tipurile de acţiuni implementate de API-ul JSP fiind:

<jsp:element name="xmlElement">
    <jsp:attribute name="xmlAttribute">
         Attribute Value
    </jsp:attribute>
    <jsp:body>
        Body for XML element
    </jsp:body>
</jsp:element>

<xmlElement xmlAttribute="Attribute Value">
   Body for XML element 
</xmlElement>

<jsp:useBean id="myObject" class="myPackage.myClass" />

<jsp:useBean id="myObject" class="myPackage.myClass" />
...
<jsp:getProperty name="myObject" property="myProperty"/>

<jsp:useBean id="myObject" class="myPackage.myClass">
    <jsp:setProperty name="myObject" property="myProperty" value="myValue" ... />
</jsp:useBean>
<jsp:useBean id="myObject" class="myPackage.myClass" />
...
<jsp:setProperty name="myObject" property="myProperty" value="myValue" ... />

<jsp:forward page="myJSPPage.jsp" />

<jsp:include page="myJSPPage.jsp" flush="true" />

<jsp:plugin type="applet" codebase="mydir" code="MyClass.class" width="100" height="100">
    <jsp:param name="paramname" value="paramvalue" />
    <jsp:fallback>
        Unable to load Java Plugin
    </jsp:fallback>
</jsp:plugin>

<jsp:text>My text template</jsp:text>

Un scriplet conţine cod sursă Java (declaraţii de variabile şi metode, expresii) care va fi plasat în metoda de tip service() ce se va genera în servlet-ul paginii JSP respective.

<% Java code fragment %>

<jsp:scriptlet>
   Java code fragment
</jsp:scriptlet>

Acest cod va fi executat pe server atunci când se realizează o cerere pentru pagina JSP care conţine scriplet-ul, iar rezultatul va fi plasat în răspunsul care este transmis clientului.

De regulă, utilizarea scripleţilor este de evitat în paginile JSP întrucât separarea dintre logica aplicaţiei şi prezentare nu mai este atât de evidentă, codul fiind şi mai dificil de întreţinut. Recursul la această tehnologie se face numai pentru a beneficia de facilităţile pe care le pune la dispoziţie limbajul de programare Java şi numai în situaţia în care un comportament similar nu poate fi obţinut prin folosirea EL (Expression Language) împreună cu metodele din bibliotecile JavaServer Pages Standard Tag Library.

O expresie este un scriplet, cuprins între <%= şi %>, evaluat în momentul în care este rulat servlet-ul şi convertit la tipul String, fiind inserat în pagina JSP acolo unde este apelat, putând fi inclusă oriunde, fie că se găseşte sau nu în cadrul unei etichete HTML. Ea poate conţine orice expresie care este validă conform specificaţiei Java, însă nu este încheiată prin ;, ca de obicei.

<%= expression %>

<jsp:expression>
    expression
</jsp:expression>

O declaraţie permite precizarea de variabile sau de metode, similar cu modul în care s-ar face într-o clasă, domeniul de vizibilitate fiind pe tot parcursul paginii respective. În servlet-ul corespunzător paginii JSP, declaraţiile vor fi incluse astfel încât să poată fi accesate din toate metodele acesteia.

<%! declaration; [declaration; ]+ %>

<jsp:declaration>
    declaration;
    [declaration; ]+
</jsp:declaration>

În JSP pot fi referite obiecte implicite, disponibile la nivelul fiecărei pagini, putând fi utilizate fără a fi declarate în prealabil. Obiectele implicite mai sunt numite şi variabile predefinite.

Astfel de obiecte vor fi disponibile doar în cadrul metodei _jspService(), astfel încât referirea acestora în cadrul unei declaraţii JSP nu are sens.

Este important ca programatorii să cunoască denumirile acestor obiecte implicite precum şi domeniul lor de vizibilitate, astfel încât să le poată accesa funcţionalitatea în acelaşi mod în care ar fi făcut-o în cadrul clasei Java Servlet corespunzătoare, în care acesteau erau declarate fie ca parametrii ai metodelor respective, fie se putea obţine o instanţă a lor pornind de la obiectele cerere şi răspuns. Prin acestea, tehnologiile Java Servlet şi JavaServer Pages sunt echivalente, oferind aceeaşi funcţionalitate şi aceeaşi uşurinţă în utilizare.

Un obiect request este creat de fiecare dată când un client solicită o pagină JSP, acesta oferind metode spre a obţine informaţii din antetele HTTP (Accept, Accept-Charset, Accept-Encoding, Accept-Language, Authorization, Cache-Control, Connection, Content-Length, Cookie, Host, If-Modified-Since, If-Unmodified-Since, Referer, User-Agent). Fiind derivat din javax.servlet.http.HttpServletRequest, metodele pe care le pune la dispoziţia programatorilor acest obiect sunt aceleaşi ca în cazul utilizării ca parametru al metodei service() din cadrul Java Servlets.

Astfel, cele mai frecvent folosite metode sunt:

• Object getAttribute(String) – întoarce valoarea obiectului identificat prin numele său (transmis ca parametru) – convertit la Object sau null dacă obiectul solicitat nu există;
• Enumeration getAttributeNames() – întoarce o enumerare conţinând numele tuturor atributelor disponibile în cadrul cererii;
• String getAuthType() – întoarce numele mecanismului de autentificare utilizat pentru securizarea servlet-ului sau null dacă nu se foloseşte un astfel de mecanism;
• String getCharacterEncoding() – întoarce denumirea schemei de codificare utilizată pentru corpul cererii;
• int getContentLength() – întoarce dimensiunea (în octeţi) a corpului cererii disponibilă în fluxul de intrare, sau -1 dacă această valoare nu e cunoscută;
• String getContentType() – întoarce tipul MIME al corpului cererii sau null dacă tipul nu este cunoscut;
• String getContextPath() – întoarce porţiunea din URI-ul cererii care indică contextul acesteia;
• Cookie[] getCookies() – întoarce toate obiectele Cookie care au fost transmise de client împreună cu cererea sa;
• String getHeader(String) – întoarce valoarea antetului specificat din cadrul cererii sub formă de şir de caractere;
• Enumeration getHeaderNames() – întoarce o enumerare ce cuprinde numele tuturor antetelor conţinute de cerere;
• int getIntHeader(String) – întoarce valoarea antetului specificat din cadrul cererii sub formă de întreg;
• ServletInputStream getInputStream() – întoarce corpul cererii (ca date binare) folosind un ServletInputStream;
• Locale getLocale() – întoarce localizarea preferată a conţinutului, în funcţie de valoarea conţinută de antetul Accept-Language;
• String getMethod() – întoarce numele metodei HTTP prin care a fost transmisă cererea (GET, POST, PUT, OPTIONS, TRACE, DELETE);
• String getParameter(String) – întoarce valoarea parametrului specificat (prin nume) în cadrul cererii ca şir de caractere sau null dacă nu există;
• Enumeration getParameterNames() – întoarce o enumerare incluzând denumirile tuturor parametrilor din cadrul cererii;
• String[] getParameterValues(String) – întoarce un vector de obiecte de tip şir de caractere conţinând toate valoarile pe care le deţine parametrul identificat (prin nume) în cadrul cererii sau null dacă nu există;
• String getPathInfo() – întoarce informaţii suplimentare referitoare la cale asociate cu URL-ul transmis împreună cu cererea;
• String getProtocol() – întoarce numele şi versiunea protocolului prin care a fost transmisă cererea;
• String getQueryString() – întoarce un şir de caractere reprezentând interogarea cuprinsă în URL după cale;
• String getRemoteAddr() – întoarce adresa IP (Internet Protocol) a clientului care a transmis cererea;
• String getRemoteHost() – întoarce numele complet al maşinii de pe care clientul a transmis cererea;
• String getRemoteUser() – întoarce numele utilizatorului autentificat care a transmis cererea sau null dacă utilizatorul nu este autentificat;
• String getRequestURI() – întoarce partea din URL-ul asociat cererii începând de la numele protocolului până la şirul ce reprezintă interogarea din cadrul cererii HTTP;
• String getRequestedSessionId() – întoarce identificatorul sesiunii specificat de client în cerere;
• int getServerPort() – întoarce portul pe care a fost primită cererea;
• String getServletPath() – întoarce partea din URL-ul asociat cererii care invocă pagina JSP;
• HttpSession getSession([boolean]) – întoarce sesiunea asociată cererii sau, dacă aceasta nu există (iar parametrul metodei, în caz că este utilizat, are valoarea true), asociază cererii o sesiune nouă;
• boolean isSecure() – indică dacă cererea a fost transmisă folosind un canal sigur (cum este HTTPS).

O listă cu antetele HTTP transmise prin intermediul cererii poate fi obţinută astfel:

...
<table>
    <tr><th>Header Name</th><th>Header Value</th></tr>
    <%
        Enumeration headers = request.getHeaderNames();
        while (headers.hasMoreElements()) {
            String headerName = (String)headers.nextElement();
            String headerValue = request.getHeader(headerName);
    %>
        <tr><td><%= headerName %></td><td><%= headerValue %></td></tr>
    <%
        }
    %>
</table>
...

Un obiect response este de asemenea creat de fiecare dată de către server, conţinând:

• starea (numele protocolului și versiunea acestuia, codul reprezentând starea și un mesaj de dimensiuni mici care reprezintă o descriere a stării);
• antetele HTTP (Allow, Cache-Control, Connection, Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-Type, Expires, Last-Modified, Location, Refresh, Retry-After, Set-Cookie);
• documentul reprezentând pagina Internet care va fi afişată în browser.

Fiind derivat din javax.servlet.http.HttpServletResponse, metodele pe care le pune la dispoziţia programatorilor acest obiect sunt aceleaşi ca în cazul utilizării ca parametru al metodei service() din cadrul Java Servlets.

Astfel, cele mai frecvent folosite metode sunt:

• void addCookie(Cookie) – adaugă la răspuns obiectul Cookie specificat;
• void addDateHeader(String, long) – adaugă la răspuns un antet reprezentând o dată calendaristică, având numele şi valoarea specificate ca parametrii ai metodei;
• void addHeader(String, String) – adaugă la răspuns un antet având numele şi valoarea (şir de caractere) specificate ca parametrii ai metodei;
• void addIntHeader(String, int) – adaugă la răspuns un antet având numele şi valoarea (număr întreg) specificate ca parametrii ai metodei;
• boolean containsHeader(String) – verifică dacă un antet (indicat prin nume, dat ca parametru) a fost specificat în cadrul răspunsului;
• String encodeRedirectURL(String) – codifică URL-ul specificat ca parametru pentru a fi utilizat de metoda sendRedirect sau dacă nu este necesară codificarea, îl lasă neschimbat;
• String encodeURL(String) – codifică URL-ul specificat ca parametru (incluzând identificatorul sesiunii în cadrul său) sau dacă nu este necesară codificarea, îl lasă neschimbat;
• void flushBuffer() – forţează afişarea conţinutului zonei de memorie tampon în browser;
• boolean isCommitted() – verifică dacă răspunsul a fost transmis către client;
• void reset() – elimină toate informaţiile din zona de memorie tampon, inclusiv coduri de statut şi antete;
• void resetBuffer()– elimină conţinutul zonei de memorie tampon, menţinând însă codurile de statut şi antetele intacte;
• void sendError(int[, String]) – transmite un răspuns către client reprezentând o eroare indicată prin codul său (şi eventual printr-un mesaj) eliminând şi conţinutul zonei de memorie tampon;
• void sendRedirect(String) – transmite clientului un răspuns temporar de redirectare către o locaţie indicată prin URL-ul dat ca parametru;
• void setBufferSize(int) – stabileşte dimensiunea preferată (în octeţi) pentru zona de memorie ce reţine conţinutul răspunsului;
• void setCharacterEncoding(String) – stabileşte mecanismul de codificare a caracterelor (setul de caractere MIME) corespunzând răspunsul transmis către client;
• void setContentLength(int) – stabileşte dimensiunea conţinutului transmis către client ca răspuns (pentru protocolul HTTP se stabilește valoarea pe care o are antetul Content-Length);
• void setContentType(String) – stabileşte tipul de conţinut corespunzător răspunsului transmis către client, dacă această operaţie nu s-a produs deja;
• void setDateHeader(String, long) – stabileşte un antet reprezentând o dată calendaristică având numele şi valoarea specificate ca parametrii ai metodei;
• void setHeader(String, String) – stabileşte un antet cu numele şi valoarea (şir de caractere) specificate ca parametrii ai metodei;
• void setIntHeader(String, int) – stabileşte un antet cu numele şi valoarea (număr întreg) specificate ca parametrii ai metodei;
• void setLocale(Locale) – stabileşte localizarea răspunsului, dacă acesta nu a fost transmis către client;
• void setStatus(int) – stabileşte codul de stare pentru răspuns.

Stabilirea unor valori corespunzătoare antetelor HTTP din răspuns poate fi realizat astfel:

...
<%
    response.setDateHeader("Last-Modified",System.currentTimeMillis());
    response.setHeader("Content-Type","text/html");
    response.setIntHeader("Refresh", 60);
%>
...

În exemplu, se stabileşte valoarea antetului Last-Modified ca fiind momentul curent, tipul conţinutului pe care îl are transmis către client (indicat de antetul Content-Type) ca fiind un document HTML, forţând reîncărcarea paginii în mod automat (prin antetul Refresh) la fiecare 60 de secunde.

Obiectul out este echivalentul obiectului PrintWriter din Java Servlets, fiind utilizat la afişarea conţinutului dinamic în cadrul paginii JSP, atunci când aceasta nu se poate face prin intermediul unor etichete HTML (eventual combinate cu expresii JSP).

Iniţial, obiectul este instanţiat diferit în funcţie de activarea mecanismului de utilizare a unei zone de memorie tampon (aşa cum este specificat de atributul buffered al directivei page). Metodele print şi println pot fi utilizate spre a afişa conţinutul unor obiecte cu tipurile boolean, char, String, int, long, float, double, Object şi altele. De asemenea, metoda flush() este folosită pentru a transmite conţinutul zonei de memorie tampon către client, golind conţinutul fluxului de ieşire.

Obiectul session este creat în mod automat (nu mai este necesară iniţializarea sau obţinerea dintr-un obiect de tip request prin metoda getSession()) pentru fiecare client ce accesează pagina în cauză. Dezactivarea acestui tip de comportament poate fi realizată doar prin intermediul atributului cu acelaşi nume din directiva page.

Metodele pe care le pune la dispoziţie acest obiect sunt cele specificate de interfaţa javax.servlet.http.HttpSession:

• Object getAttribute(String) – întoarce obiectul care este asociat numelui transmis ca parametru al metodei în cadrul sesiunii sau null dacă nu există nici un obiect asociat;
• Enumeration getAtrributeNames() – întoarce o enumerare ce conţine denumirile tuturor obiectelor asociate sesiunii;
• long getCreationTime() – întoarce momentul la care a fost creată sesiunea, exprimată în milisecunde raportate la data 1 ianuarie 1970 (GMT);
• String getId() – întoarce un şir de caractere care identifică în mod unic sesiunea;
• long getLastAccessedTime() – întoarce momentul la care clientul a transmis ultima dată o cerere asociată sesiunii, exprimată în milisecunde raportate la data 1 ianuarie 1970 (GMT);
• int getMaxInactiveInterval() – întoarce perioada de timp maximă, exprimată în secunde, în care containerul servletului va menţine sesiunea, între diferite accesări provenite de la clienţi;
• void invalidate() – invalidează sesiunea, eliminând orice asociere a unui obiect la aceasta;
• boolean isNew() – stabileşte dacă clientul nu are cunoştinţă de sesiune sau dacă alege să nu participe la aceasta;
• void removeAttribute(String) – elimină asocierea obiectului identificat prin numele transmis ca parametru al metodei la sesiune;
• void setAttribute(String, Object) – asociază la sesiune un obiect ale cărui nume şi valoare sunt specificate ca parametrii ai metodei;
• void setMaxInactiveInterval(int) – stabileşte perioada de timp maximă, exprimată în secunde, care se poate scurge între diferite accesări provenite de la clienţi până când sesiunea va fi invalidată de containerul servletului; valoarea poate fi specificată şi în fişierul de configurare web.xml:

  <session-config>
      <session-timeout>60</session-timeout>
  </session-config>

  Această valoare va suprascrie valoarea implicită specificată de serverul Apache Tomcat 8.x, care este de 30 de minute. În fişierul de configurare web.xml timpul de expirare va fi specificat, spre diferenţă de metoda setMaxInactiveInterval() nu în secunde, ci în minute.

În afară de sesiuni, pentru gestiunea comunicaţiei dintre client şi server, pot fi utilizate cookie-uri, fişiere text reţinute pe maşina client (dacă aceasta permite stocarea lor) şi citite de server pentru a identifica în mod unic conexiunea respectivă. Acestea sunt transmise de regulă prin antete HTTP, câmpul Set-Cookie reţinând perechi de tipul cheie-valoare pentru atributele name, expires, path şi domain. De fiecare dată când clientul va accesa o pagină care corespunde cu valorile reţinute de atributele path şi domain, în cazul în care nu a fost depăşită perioada specificată de atributul expires, cookie-ul va fi inclus în antetele HTTP transmise către server.

Metodele pe care le pune la dispoziţie clasa Cookie sunt:

• String getComment() – întoarce comentariul care descrie scopul obiectului cookie sau null dacă nu există nici un comentariu asociat;
• String getDomain() – returnează domeniul pentru care se aplică obiectul cookie;
• int getMaxAge() – pune la dispoziţie durata de viaţă (exprimată în secunde) pentru obiectul cookie; valoarea -1 exprimă faptul că obiectul cookie va persista până când se va părăsi browserul;
• String getName() – obţine denumirea obiectului cookie; danumirea unui obiect cookie nu mai poate fi modificată după crearea sa;
• String getPath() – reflectă calea pentru care se aplică obiectul cookie;
• String getValue() – redă valoarea asociată obiectului cookie;
• void setComment(String) – fixează un comentariu care indică scopul obiectului cookie, acesta fiind util în situaţia în care browserul îl afişează utilizatorului pentru a lua o decizie în privinţa sa;
• void setDomain(String) – indică domeniul pentru care se aplică obiectul cookie;
• void setMaxAge(int) – stabileşte timpul (exprimat în secunde) care ar trebui să se scurgă înainte de expirarea obiectului cookie; în cazul în care atributul nu este precizat, obiectul cookie va exista doar pe parcursul sesiunii curente;
• void setPath(String) – setează calea pentru care se aplică obiectul cookie; dacă acest atribut nu este specificat, obiectul cookie este transmis pentru toate URL-urile care se găsesc în acelaşi director sau subdirector cu pagina curentă;
• void setSecure(boolean) – determină dacă obiectul cookie ar trebui transmis numai prin legături criptate;
• void setValue(String) – precizează valoarea asociată cu obiectul cookie.

Utilizarea unui obiect Cookie presupune crearea sa, precizarea duratei (maxime) de viaţă şi transmiterea sa în cadrul obiectului response la client prin metoda addCookie().

Crearea unui obiect de tip Cookie implică specificarea unei denumiri şi a valorii asociate. Nici denumirea şi nici valoarea asociată nu trebuie să conţină în cadrul lor caracterele [, ], (, ), =, ,, “, /, ?, @, :, ;.

Totodată, ştergerea presupune stabilirea duratei (maxime) de viaţă nule înainte de a fi inclus în antetele HTTP către browserul ce se ocupă cu reţinerea sa.

Obiectul application este de fapt un wrapper pentru obiectul ServletContext al servletului asociat paginii JSP, fiind o reprezentare a acesteia pe parcursul întregului său ciclu de viaţă, fiind iniţializat în metoda _jspInit() şi distrus în metoda _jspDestroy(). Este folosit împreună cu metodele getAttribute(String) şi setAttribute(String, Object) atunci când se doreşte ca proprietăţile respective să aibă un domeniu de vizibilitate corespunzător întregii aplicaţii, adică tuturor paginilor care o alcătuiesc. O funcţionalitate ce se pretează folosirii acestui obiect este determinarea numărului de accesări al aplicaţiei respective. Într-o astfel de situaţie, pentru a se evita situaţia pierderii datelor în cazul repornirii aplicaţiei (serverului web care o găzduieşte), trebuie asigurată şi persistenţa acestora prin stocarea lor într-o bază de date.

Obiectul config este şi el un wrapper pentru obiectul ServletConfig, permiţând programatorilor să acceseze parametrii de iniţializare ai motorului Java Servlet sau JSP, obţinuţi prin metodele getInitParameter(String), respectiv getInitParameterNames(). Numele servletului asociat, aşa cum este specificat prin elementul <servlet-name> din fişierul de configurare web.xml, poate fi accesat prin metoda getServletName().

Obiectul pageContext este folosit ca o reprezentare a întregii pagini JSP, având scopul de a accesa informaţia cu privire la aceasta, evitând majoritatea detaliilor cu privire la implementare. Acest obiect reţine referinţe către obiectele request şi response, iar obiectele config, session şi out pot fi obţinute prin atribute ale sale. De asemenea, el conţine şi informaţii cu privire la directivele transmise paginii JSP. În cadrul său sunt definite mai multe câmpuri, printre care şi domeniile de vizibilitate PAGE_SCOPE, REQUEST_SCOPE, SESSION_SCOPE, APPLICATION_SCOPE. Implementează mai multe metode, majoritatea fiind moştenite din clasa javax.servlet.jsp.JspContext. Se pot realiza operaţii pe atribute (stabilire, obţinere sau ştergere) de fiecare dată specificându-se şi domeniul său de vizibilitate.

Obiectul page este o referinţă către instanţa paginii JSP curente, în fapt un sinonim pentru obiectul this.

Obiectul exception este un wrapper ce conţine excepţia generată de către pagina anterioară, fiind folosit pentru a construi un răspuns adecvat la eroarea în cauză. Acesta este disponibil numai în paginile JSP de eroare, indicate prin atributul errorPage al directivei page spre a fi invocate în momentul în care se produc anumite erori.

O excepţie poate fi:

• verificată (o eroare de utilizator care nu poate fi prevăzută de programator, generată în momentul compilării);
• generată la rulare (ignorată la momentul compilării, dar care ar fi putut fi evitată prin anumite mecanisme de prevenţie);
• eroare, în privinţa căreia nu se poate face mare lucru, depăşind posibilităţile de intervenţie atât din partea utilizatorului cât şi din partea programatorului.

Fiind un obiect de tip java.lang.Throwable, pentru un astfel de obiect pot fi apelate metodele:

• String getMessage() – oferă un mesaj detaliat cu privire la excepţia care s-a produs; acest mesaj detaliat cu privire la excepţia care s-a produs poate fi iniţializat în constructorul obiectului Throwable.
• Throwable getCause() – întoarce cauza excepţiei;
• String toString() – întoarce numele clasei concatenat cu mesajul detaliat referitor la excepţia care s-a produs;
• void printStackTrace() – afişează rezultatul metodei toString() împreună cu stiva de erori la fluxul de ieşire pentru erori System.err;
• StackTraceElement[] getStackTrace() – întoarce un vector conţinând fiecare element al stivei de erori; elementul de pe poziţia 0 reprezintă vârful stivei de erori, iar ultimul element reprezintă baza stivei de erori (metoda de la apelul căreia a pornit eroarea);
• Throwable filllnStackTrace() – completează stiva de erori a obiectului Throwable cu stiva de erori curentă.

Aceste metode pot fi obţinute şi prin intermediul obiectului pageContext care dispune de atributele exception (prin intermediul căruia poate fi vizualizată şi stiva de erori – atributul stackTrace) şi errorData (ce oferă acces la calea relativă a paginii JSP care a generat eroarea – atributul URI şi codul de statut corespunzător excepţiei – atributul statusCode).

Alternativ, în cadrul unui scriplet se poate folosi un bloc try { … } catch, tratarea erorii realizându-se în cadrul aceleiaşi pagini JSP. Totuşi, o astfel de abordare trebuie evitată, recurgându-se la ea numai în situaţia în care se vrea ca recuperarea din eroare să se realizeze cât mai rapid.

Filtrele sunt folosite pentru a intercepta cererile de la un client înainte ca acestea să acceseze anumite resurse sau pentru a gestiona răspunsurile generate de server înainte ca acestea să fie transmise înapoi. Funcţionalitatea unui filtru trebuie specificată în metoda doFilter(), care va fi suprascrisă de către orice clasă ce implementează interfaţa javax.servlet.Filter:

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws java.io.IOException, javax.servlet.ServletException

Pot fi implementate filtre pentru autentificare, filtre pentru compresia datelor, filtre de criptare filtre care declanşează evenimente de acces a unor resurse, filtre de conversie a imaginilor, filtre pentru jurnalizare şi auditare, lanţuri de filtre MIME-TYPE, filtre pentru parsare şi filtre XSLT care transformă conţinutul XML.

În afară de această metodă, mai trebuie implementate şi metodele init() şi destroy().

Asocierea dintre un filtru şi un Java Servlet sau pagină JSP precum şi ordinea execuţiei acestora este determinată din fişierul de configurare web.xml în care elementul <filter> indică numele filtrului, clasa asociată precum şi parametrii folosiţi la iniţializarea acestuia, iar elementul <filter-mapping> specifică asocierile (şi ordinea) dintre un filtru şi clasele Java Servlet respectiv paginile JSP. Ordinea în care sunt executate filtrele pentru un Java Servlet respectiv pagină JSP este aceeaşi cu cea în care acestea sunt mapate în fişierul de configurare web.xml. Dacă se doreşte ca un filtru să fie asociat la mai multe resurse, se poate folosi masca /* în cadrul elementului <url-pattern>.

Încărcarea unui fişier pe server (la locaţia specificată de parametrul file-upload din fişierul de configurare web.xml) se face prin intermediul unui formular care specifică ca tip de criptare (enctype) multipart/form-data în care controlul pentru intrare (input) este de tip (type) file:

<context-param>
    <param-name>file-upload</param-name>
    <param-value>
        My Upload Location
    </param-value>
</context-param>

<form action="myJSPPage.jsp" method="POST" enctype="multipart/form-data">
    <input type="file" name="file" size="100" />
    <br />
    <input type="submit" value="Upload File" />
</form>

Pentru procesarea în cadrul paginii JSP a încărcării fişierului pe server, poate fi folosită biblioteca commons-fileupload dezvoltată de Apache ce oferă posibilitatea încărcării mai multor fişiere simultan, implementând metode pentru obţinerea diferitelor proprietăţi ale resursei respective (cale absolută, denumire, dimensiune) precum şi funcţionalităţi precum citirea din memorie şi scrierea pe disc.

Frecvent, invocarea altor resurse se referă la redirectare, realizată atunci când documentul s-a mutat la o altă adresă sau atunci când se doreşte echilibrarea încărcării. În acest sens se foloseşte metoda sendRedirect() apelată pe obiectul response(), care primeşte ca parametru URL-ul resursei către care se doreşte a se realiza redirectarea. Alternativ, acest comportament se poate obţine prin stabilirea unor valori pentru antetele HTTP:

response.setIntHeader("Status", response.SC_MOVED_TEMPORARILY);
response.setHeader("Location", myLocation);

În cadrul aplicaţiilor web, se lucrează destul de des cu obiecte de tipul dată calendaristică, integrarea lor în cadrul tehnologiei Java Servlets sau JSP făcându-se prin obiecte de tip java.util.Date, ce pot fi create fie prin intermediul unui constructor vid (caz în care obiectul va conţine data curentă) sau al unui constructor ce primeşte un parametru de tip long, ce indică durata, exprimată în milisecunde, care s-a scurs de la 1 ianuarie 1970 (GMT). Operaţiile pe care le suportă un astfel de obiect sunt after(Date), before(Date), clone(), compareTo(Date[|Object]), equals(Object), getTime(), hasCode(), setTime(long), toString(). Formatarea unui astfel de obiect se poate realiza folosind clasa SimpleDateFormat în care anumite caractere codifică atributele obiectului Date.

De asemenea, se întâlneşte frecvent necesitatea de a transmite mesaje folosind poşta electronică, o astfel de funcţionalitate putând fi integrată prin API-ul JavaMail şi framework-ul Java Activation Framework (JAF).

Un obiect Session necesar construirii unui mesaj ce poate fi transmis prin poşta electronică va fi construit dintr-o serie de proprietăţi între care obligatorie este mail.smtp.host. În situaţia în care serverul de poştă electronică necesită autentificare, vor fi precizate şi atributele mail.user / mail.password. Obiectul reprezentând mesajul propriu-zis va avea tipul MimeMessage, precizarea câmpurilor corespunzătoare (From:, To:, Subject: şi Text:) realizându-se prin metodele:

• void setFrom(InternetAddress) – parametrul metodei construindu-se pornind de la adresa de poştă electronică a destinatarului;
• void addRecipients(Message.RecipientType, Address[]), unde
  • tipul poate avea valorile:
    • Message.RecipientType.TO;
    • Message.RecipientType.CC (CarbonCopy);
    • Message.RecipientType.BCC (Blind Carbon Copy).
  • vectorul de adrese se creează folosind constructorul InternetAddress căruia i se transmite ca parametru adresa de poştă electronică a expeditorului.
• void setSubject(String) – se stabileşte subiectul mesajului;
• void setText(String) – se precizează corpul mesajului;
• void setContent(String, String) – se precizează corpul mesajului, având atât conţinutul, cât şi formatul precizate ca parametri; în acest mod se pot transmite documente care au alt format în afară de plain-text, de exemplu HTML / XML. În acest caz, dimensiunea pe care o poate avea corpul mesajului nu este limitată decât de serverul de poştă electronică.

Transmiterea propriu-zisă a mesajului se face prin metoda statică send() definită în clasa Transport, aceasta generând o excepţie MessagingException dacă mesajul nu a putut fi transmis din diverse motive.

De asemenea, pot fi incluse ataşamente prin construirea unui obiect MimeMultiPart la care se adaugă (folosind metoda addBodyPart()) fragmente ale ataşamentului respectiv, de tipul MimeBodyPart. Un astfel de obiect suportă metodele setText(String) pentru a indica o corpul mesajului, respectiv setDataHandler(DataHandler) şi setFileName(String) pentru a specifica fişierul care conţine ataşamentul. Indicarea conţinutului ca fiind un obiect de tipul MimeMultiPart se face tot prin metoda setContent().

Un obiect de tip DataHandler se obţine dintr-un obiect FileDataSource, care la rândul său este construit pornind de la denumirea fişierului în cauză, la care se adaugă şi calea către el, relativă sau absolută. În situaţia în care nu se specifică nici o cale, fişierul va fi căutat în acelaşi director în care este plasată clasa Java Servlet sau pagina JSP care încearcă transmiterea sa prin intermediul poştei electronice.

Informaţiile cu privire la destinatar, expeditor, subiect şi conţinut pot fi incluse într-un formular, apoi preluate din obiectul request astfel încât transmiterea mesajului să se facă pe baza acestora.

<%@ page import="javax.mail.*", "javax.mail.internet.*", "javax.activation.*" %>
...
<%
    Properties properties = System.getProperties();
    properties.setProperty("mail.smtp.host","localhost");
    properties.setProperty("mail.user",myUser);
    properties.setProperty("mail.password",myPassword);
    Session mailSession = Session.getDefaultInstance(properties);
    try {
        MimeMessage mailMimeMessage = new MimeMessage(maiSession);
        mailMimeMessage.setFrom(new InternetAddress(from));
        mailMimeMessage.addRecipient(Message.RecipientType.TO, new InternetAddress(to));
        mailMimeMessage.setSubject("My Subject");
        Multipart mailMultipart = new MimeMultipart();
        BodyPart mailBodyPart;
        mailBodyPart = new MimeBodyPart();
        mailBodyPart.setText("My Mail Body");
        mailMultipart.addBodyPart(mailBodyPart);
        mailBodyPart = new MimeBodyPart();
        String filename = "myFileName.myExtension";
        mailBodyPart.setDataHandler(new DataHandler(new FileDataSource(filename)));
        mailBodyPart.setFileName(filename);
        mailMultiPart.addBodyPart(mailBodyPart);
        mailMimeMessage.setContent(mailMultiPart);
        Transport.send(mailMimeMessage);
    } catch (MessagingException exception) {
        System.out.println("An exception has occurred: "+exception.getMessage();
        if (Constants.DEBUG)
            exception.printStackTrace();
    }
%>

EL (Expression Language) pune la dispoziţia utilizatorilor un mecanism prin care nivelul de prezentare poate comunica cu nivelul de logică al aplicaţiei (mai ales componente Java Beans), implementând operaţii aritmetice şi logice folosind tipuri de date întregi, reale, şiruri de caractere, valori adevărat / fals şi null.

Tehnologia Java Server Pages foloseşte Expression Language pentru:

• evaluarea imediată şi leneşă a expresiilor prin realizarea de operaţii aritmetice şi logice în mod dinamic;
• posibilitatea de a stabili şi de a obţine informaţii (având structuri de date variate), în special proprietăţi ale componentelor Java Beans, pe baza interacţiunii cu utilizatorul;
• folosirea de obiecte implicite;
• abilitatea de a invoca metode (publice şi statice).

În Expression Language pot fi folosite următoarele tipuri de expresii:

• expresii cu evaluare imediată (a căror valoare este stabilită instant de către tehnologia împreună cu care este utilizată, în cazul de faţă Java Server Pages) şi expresii cu evaluare leneşă (a căror valoare poate fi evaluată ulterior de către tehnologia împreună cu care este utilizată);
• expresii valoare (ce referă date) şi expresii metodă (ce invocă metode);
• expresii rvalue (care pot doar să citească date dintr-un obiect extern) şi expresii lvalue (care pot atât să citească cât şi să scrie date din / într-un obiect extern).

Expresiile cu evaluare imediată, desemnate prin sintaxa ${expression}, sunt calculate înainte ca pagina Internet să fie afişată. Aceste expresii pot fi folosite numai ca valori ale unei etichete care acceptă expresii evaluate în momentul rulării şi sunt întotdeauna expresii de tip rvalue.

<input type="submit" name="${inputName}" value="${inputValue}">

Pentru expresiile cu evaluare leneşă, pentru care se foloseşte sintaxa #{expression}, valoarea poate fi determinată mai târziu, prin mecanisme ce ţin de tehnologia împreună cu care e folosită Expression Language, pe parcursul ciclului de viaţă al paginii Internet. Aceste expresii pot fi expresii valoare utilizate atât pentru a citi cât şi pentru a scrie informaţii dar şi expresii metodă.

<table><tr><td>#{inputName}</td><td>#{inputValue}</td></tr></table>

Expresiile de tip valoare pot fi clasificate în expresii rvalue şi lvalue după cum dispun sau nu de posibilitatea de a scrie informaţii. Expresiile cu evaluare imediată sunt întotdeauna expresii rvalue, în timp ce expresiile cu evaluare leneşă sunt de regulă expresii lvalue.

Expresia ${entitybean.attribute} obţine valoarea unui atribut din cadrul unei componente Java Bean, evaluându-l instant şi transmiţând mai departe rezultatul obţinut.

Expresia #{entitybean.attribute} poate avea acelaşi comportament ca expresia de mai sus, însă eticheta în cadrul căreia este folosită poate decide evaluarea sa la un moment de timp ulterior. Mai mult, atunci când pagina Internet este solicitată, expresia va fi de tipul rvalue (obţinând valoarea atributului), în timp ce în cadrul etapei postback ea poate fi de tipul lvalue (putând stabili valoarea atributului).

Toate expresiile pot referi următoarele tipuri de obiecte, împreună cu atributele lor: componente Java Beans, colecţii, structuri de date Java de tip enumerare, obiecte implicite. Pentru a le utiliza, se foloseşte o expresie în care variabila este reprezentată de denumirea obiectului:

${myObject}
#{myObject}

Container-ul paginii Internet evaluează variabila ce apare în expresie căutându-i valoarea ce este oferită de PageContext.findAttribute(“myObject”), domeniile de vizibilitate investigate fiind page, request, session şi application. Dacă obiectul nu este găsit, se returnează o valoare null. Pot fi utilizare motoare EL particularizate pentru a se modifica modul în care sunt evaluate expresiile.

Pentru a referi proprietăţile unei componente Java Bean sau a instanţei unei enumerări, elementele unei colecţii sau atributele unui obiect implicit pot fi folosite notaţiile . sau [], care sunt echivalente. Pentru şirurile de caractere se pot folosi atât apostroafe, cât şi ghilimele.

Următoarele expresii sunt echivalente:

${myObject.myAttribute}

${myObject['myAttribute']}

${myObject["myAttribute"]}

Expresii similare pot fi formate şi pentru asigurarea evaluării leneşe.

De asemenea, pot fi folosite şi combinaţii ale operatorilor . şi [] în cadrul aceleiaşi expresii.

Pentru accesarea elementelor unui vector sau al unei liste, trebuie folosite valori literale (fără apostroafe sau ghilimele) ce pot fi convertite la un întreg sau notaţia [] ce primeşte de asemenea un întreg, în timp ce pentru un obiect de tip Map accesarea implică folosirea unei chei de tip şir de caractere:

// array or list: firstComponent can be narrowed to 0
${myObject.myAttribute[0]}
${myObject.myAttribute[firstComponent]}

// map
${myObject.myAttribute["firstComponent"]}

În Expression Language pot fi folosite următoarele tipuri de date:

• Boolean: poate avea valorile true sau false;
• numere întregi, numere reale: utilizate la fel ca în Java;
• String (şir de caractere), referite cu apostroafe sau ghilimele, \ fiind folosit pe post de caracter escape (” → \“, ' → \', \ → \\);
• null.

Expresiile de tip valoare pot fi utilizate în text static sau în etichete (standard sau definite de utilizator) care acceptă o expresie. Unele etichete acceptă doar expresii de tip rvalue în timp ce alte expresii pot accepta şi expresii de tip lvalue.

Valoarea unei expresii în text static este evaluată şi ulterior inclusă în pagina Internet:

<my:tag>my text1 ${expression} my text2</my:tag>

Atributul valoare al unei etichete poate fi iniţializat folosind o expresie rvalue sau lvalue astfel:

• folosind o singură expresie; expresiile sunt evaluate şi rezultatul convertit la tipul atributului respectiv:

  <my:tag value="${expression}" />
  <my:tag value="#{expression}" />

• folosind una sau mai multe expresii, separate sau înconjurate de text; se numesc expresii compuse şi sunt evaluate de la stânga la dreapta, fiecare expresie fiind convertită la tipul String şi concatenată cu alte texte, şirul de caractere rezultat fiind convertit la tipul atributului respectiv:

  <my:tag value="my text1 ${expression1} my text2 ${expression2}" />
  <my:tag value="my text1 #{expression1} my text2 #{expression2}" />

  În EL 3.0 operatorul + e folosit pentru concatenarea şirurilor de caractere.

• folosind doar text; se numesc expresii literale şi valoarea String a atributului este converită la tipul atributului respectiv

  <my:tag value="my text" />

Toate expresiile utilizate pentru a stabili valori sunt evaluate în contextul unui tip de date aşteptat. Dacă rezultatul obţinut în urma evaluării expresiei nu corespunde exact tipului de date aşteptat, se va realiza o conversie de tip.

Expresiile de tip metodă permit invocarea unei metode implementate în cadrul unei componente Java Bean, care întoarce un rezultat. De regulă, acestea sunt folosite pentru a realiza anumite procesări asociate cu controlul din contextul căruia sunt apelate, fiind invocate în momentul în care este generat un eveniment în cadrul acelui control. Întrucât o metodă poate fi invocată pe parcursul diferitelor etape ale ciclului de viaţă, expresiile de tip metodă trebuie să fie întotdeauna cu evaluare leneşă.

<my:tag id="myTagId" action="#{myObject.myValue}" />
<my:tag id="myTagId" action="#{myObject['myValue']}" />

Expresiile de tip metodă trebuie folosite întotdeauna numai în cadrul unei etichete, fie folosind o singură expresie care este evaluată şi transmisă modulului de gestiune a etichetei, putând fi invocată mai târziu sau folosind doar text. La execuţia metodei asociată expresiei în cauză, se întoarce un rezultat de tip String care este convertit la tipul aşteptat, aşa cum este definit de descriptorul bibliotecii de etichete.

Expresiile de tip metodă pot fi utilizate pentru a invoca funcţii care primesc un set de parametrii (0 sau mai mulţi, separaţi prin virgulă). Se pot folosi atât operatorul . cât şi [], comportamentul acestora fiind similar:

myObject["myMethod"](myparameters)
myObject.myMethod(myParameters)

În Expression Language pot fi folosite şi expresii lambda, acestea fiind expresii de tip valoare ce primesc parametrii. Utilizarea acestora este comparabilă cu cazul limbajului de programare Java, cu excepţia faptului că şi corpul expresiei lambda este tot o expresie EL. O expresie lambda foloseşte operatorul →, identificatorii din stânga expresiei fiind parametrii lambda, în dreapta expresiei aflându-se o expresie EL. De obicei, se folosesc parantezele () pentru a include parametrii lambda, acestea putând fi omise dacă există un singur parametru.

O expresie lambda are un comportament asemănător cu al unei funcţii, aceasta putând fi apelată imediat sau valoarea ei poate fi asociată unei variabile ce va fi utilizată ulterior pentru invocarea metodei respective primind parametrii care vor fi disponibili la momentul respectiv.

O expresie lambda poate fi transmisă ca argument al unei metode, fiind executată în cadrul metodei respective sau poate fi inclusă la rândul ei, în altă expresie lamda.

() -> null
(x,y) -> (x+y)/2
((x,y) -> Math.sqrt(x*y))(4,9)
distance = (x1,y1,x2,y2) -> Math.sqrt(Math.sqr(x1-x2)+Math.sqr(y1-y2));
distance(1,1,2,2)

O expresie literală este evaluată la textul expresiei, care are tipul String, fiind utilizată atunci când este necesară folosirea sintaxei rezervate ${} sau #{}. Dacă se doreşte folosirea şirului de caractere ${expression} se pot folosi alternativele ${'${'}expression sau \${expression} (idem şi pentru expresii #{}). O expresie literală nu foloseşte delimitatorii ${} sau #{}.

Expresiile literale pot fi cu evaluare imediată sau cu evaluare leneşă şi pot fi atât expresii de tip valoare cât şi expresii de tip metodă. Momentul la care este evaluată o expresie depinde de contextul în care aceasta este utilizată.

În EL sunt suportate operaţii pe colecţii cum ar fi:

• mulţimi

  {1, 2, ..., n}

• liste – acestea pot conţine elemente având tipuri diferite

  {1, two, "3", ...}

• obiecte de tip map

  {"one":1, "two":2, ..., "n":n}

Prin Expression Language, se permite crearea dinamică a acestora, exploatarea lor implicând utilizarea unor obiecte de tip flux, respectiv benzi de asamblare (eng. pipeline). Astfel, metodele vor fi apelate pe fluxul de elemente obţinut din colecţia respectivă folosind metoda stream(). Întrucât unele metode întorc tot un flux de elemente, acestea pot fi înlănţuite împreună în cadrul unei benzi de asamblare . Operaţiile realizate pe fluxul de elemente nu modifică colecţia originală.

collection.stream().filter(a->a.attribute1=='value1')
                   .map(a->a.attribute2)
                   .sorted()
                   .toList()

Operaţiile suportate de fluxul de elemente sunt: allMatch(), anyMatch(), average(), count(), distinct(), filter(), findFirst(), flatMap(), forEach(), iterator(), limit(), map(), max(), min(), noneMatch(), peek(), reduce(), sorted(), substream(), sum(), toArray(), toList().

În afară de operatorii . şi [], Expression Language pune la dispoziţia programatorilor şi alţi operatori, ce pot fi folosiţi doar în expresii de tip rvalue:

În Expression Language există şi termeni rezervaţi, care nu pot fi utilizaţi ca identificatori: and, or, not, eq, ne, lt, gt, le, ge, true, false, null, instanceof, empty, div, mod.

Există posibilitatea ca expresiile EL să nu fie evaluate în cazul în care atributul isELIgnored al directivei page are valoarea true (implicit, valoarea sa este false, deci în mod obişnuit, expresiile EL vor fi evaluate într-o pagină JSP).

JSTL (JavaServer Pages Standard Tag Library) este o colecţie de etichete JSP, care implementează funcţionalitatea de bază specifică pentru numeroase aplicaţii JSP.

Etichetele JSTL pot fi clasificate, în funcţie de comportamentul pe care îl oferă utilizatorilor în mai multe grupuri:

1. etichete JSTL de bază;
2. etichete JSTL pentru formatare;
3. etichete JSTL destinate gestiunii informaţiilor dintr-o bază de date SQL;
4. etichete JSTL pentru gestiunea documentelor XML;
5. funcţii JSTL.

Pentru ca aceste funcţionalităţi să fie accesibile în pagina JSP a unei aplicaţii web, biblioteca JSTL trebuie plasată în directorul WEB-INF\lib corespunzător acesteia.

Etichetele JSTL de bază sunt cele mai frecvent utilizate, implementând funcţionalitate legată de controlul fluxului.

Pentru a putea referi aceste etichete, trebuie specificată locaţia de unde acestea pot fi încărcate.

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

Cele mai frecvent utilizate etichete JSTL de bază sunt:

<c:out value="${myObject.myAttribute}" />

<c:set value="${expression}" target="myObject" property="myAttribute" scope="page" />
<c:set value="${expression}" var="myVariabile" scope="application" />

<c:remove var="myVariable" scope="application" />

<c:catch var="${exception}"> 
    <% some expression(s) that may potentially throw an error %>
</c:catch>
<c:out value="exception: ${exception.message}" />

<c:if test="${expression}" />
    <% do some operations %>
</c:if>

<c:choose>
    <c:when test="${expression1}"><% do some operations %></c:when>
    <c:when test="${expression2}"><% do some operations %></c:when>
    ...
    <c:when test="${expressionn}"> 
        <% do some operations %>
    </c:when>
    <c:otherwise><% do some other operations %></c:otherwise>
</c:choose />

<c:import var="myVariabile" url="http://www.mysite.com" />

<c:forEach var="myVariabile" items="${myCollection}">
    <c:out value="${myVariabile}" /><br />
</c:forEach>

<c:forTokens var="myVariabile" items="${myString}" delim=",">
    <c:out value="${myVariabile}" /><br />
</c:forTokens>

<c:import var="myVariabile" url="http://www.mysite.com">
    <c:param name="param1Name" value="param1Value" />
    <c:param name="param2Name" value="param2Value" />
    ...
    <c:param name="paramnName" value="paramnValue" />
</c:import>

<c:redirect url="http://www.mysite.com">

<c:url value="http://www.mysite.com" />

Etichetele JSTL pentru formatare sunt utilizate pentru a formata şi afişa text, informaţii cu privire la dată calendaristică şi timp, numere precum şi site-uri Internet într-un format localizat.

Pentru a putea referi aceste etichete, trebuie specificată locaţia de unde acestea pot fi încărcate.

<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>

Cele mai frecvent utilizate etichete JSTL pentru formatare sunt:

<fmt:bundle basename="myBaseName">
    <fmt:message key="myPrefix.myKey" />
</fmt:bundle>
echivalent cu
<fmt:bundle basename="myBaseName" prefix="myPrefix">
    <fmt:message key="myKey" />
</fmt:bundle>

Etichetele JSTL pentru gestiunea informaţiilor într-o bază de date SQL oferă funcţionalitatea pentru interacţiunea cu baze de date relaţionale ca Oracle, MySQL sau Microsoft SQL Server.

Pentru a putea referi aceste etichete, trebuie specificată locaţia de unde acestea pot fi încărcate.

<%@ taglib prefix="sql" uri="http://java.sun.com/jsp/jstl/sql" %>

Cele mai frecvent utilizate etichete JSTL pentru gestiunea informaţiilor dintr-o bază de date sunt:

<sql:setDataSource var="connection" url="${dataBaseConnection}" 
                   user="${dataBaseUser}" password="${dataBasePassword}" />

<sql:query sql="${myQuery}" var="result" />

<sql:update dataSource="${connection}" var="count">
    <%-- some INSERT, UPDATE or DELETE query -->
</sql:update>

<sql:query dataSource="${connection}" var="result">
    SELECT FROM table WHERE attribute = ?
    <sql:param value="${missingTableAttributeValue}" />
</sql:query>

<sql:update dataSource="${connection}" var="count">
    <%-- some INSERT, UPDATE or DELETE query with one or more 
         missing attribute values -->
    <sql:param value="${missingTableAttributeValue}" />
</sql:update>

<sql:transaction dataSource="${connection}">
    <sql:update var="count1">
        <%-- some INSERT queries -->
    </sql:update>
    <sql:update var="count2">
        <%-- some UPDATE queries -->
    </sql:update>
    <sql:update var="count3">
        <%-- some DELETE queries -->
    </sql:update>
</sql:transaction>

Etichetele JSTL pentru gestiunea documentelor XML oferă posibilitatea de a manipula acest tip de resurse, implementând operaţii precum parsarea şi transformarea acestora precum şi controlul fluxului bazat pe expresii XPath.

Pentru a putea referi aceste etichete, trebuie specificată locaţia de unde acestea pot fi încărcate.

<%@ taglib prefix="x" uri="http://java.sun.com/jsp/jstl/xml" %>

Cele mai frecvent utilizate etichete JSTL pentru gestiunea documentelor XML sunt:

<x:parse xml="${myXmlDocument}" var="variable" />
<x:out select="$variable/root/element[index]/attribute" />

<x:parse xml="${myXmlDocument}" var="variable1" />
<x:set var="variable2" select="$variable1/root/element" />

<x:parse xml="${myXmlDocument}" var="variable" />
<x:if select="$variable/root/element[index]/attribute != 0" />
    The attribute of the element at index is not null!
</x:if>

<x:parse xml="${myXmlDocument}" var="variable" />
<x:forEach select="$variable/root/element/attribute" var="item" />
    <x:out select="$item" />
</x:forEach>

<x:parse xml="${myXmlDocument}" var="variable" />
<x:choose>
    <x:when select="$variable//element/attribute eq value1">
        Attribute has value 1!
    </x:when>
    <x:when select="$variable//element/attribute eq value2">
        Attribute has value 2!
    </x:when>
    ...
    <x:when select="$variable//element/attribute eq valuen">
        Attribute has value n!
    </x:when>
    <x:otherwise>
        Attribute has unknown value!
    </x:otherwise>
</x:choose>

<x:parse xml="${myXmlDocument}" var="variable" />
<c:import url="http://www.mysite.com/document.xsl" var="xslt" />
<x:transform doc="${variable}" xslt="${xslt}" />

<x:transform doc="${variable}" xslt="${xslt}" />
    <x:param name="attributeName" value="attributeValue" />
</x:transform>

Expresion Language permite folosirea de funcţii în cadrul expresiilor, acestea trebuind să fie definite în cadrul unor biblioteci de etichete predefinite, apelul său făcându-se folosind sintaxa:

${ns:function(param1, param2, ..., paramn)}

JSTL include un număr de funcţii standard, dintre care numeroase implică manipularea şirurilor de caractere. Pentru a putea referi aceste etichete, trebuie specificată locaţia de unde acestea pot fi încărcate.

<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>

Lista de funcţii standard JSTL este redată în continuare:

<c:set var="variable" value="${fn:contains(stringToBeSearched, substringToSearch)}" />

<c:set var="variable" value="${fn:containsIgnoreCase(stringToBeSearched, substringToSearch)}" />

<c:set var="variable" value="${fn:endsWith(stringToBeSearched, sufix)}" />

<c:set var="variable" value="${fn:escapeXml(stringToBeXmlEscaped)}" />

<c:set var="variable" value="${fn:indexOf(stringToBeSearched, substringToSearch)}" />

<c:set var="variable" value="${fn:join(arrayToBeJoined, separator)}" />

<c:set var="variable1" value="${fn:length(myList)}" />
<c:set var="variable2" value="${fn:length(myString)}" />

<c:set var="variable" value="${fn:length(myString, sequenceToReplace, sequenceToReplaceWith)}" />

<c:set var="variable" value="${fn:split(myString, delimiter)}" />

<c:set var="variable" value="${fn:startsWith(stringToBeSearched, prefix)}" />

<c:set var="variable" value="${fn:substring(myString, startIndex, endIndex)}" />

<c:set var="variable" value="${fn:substringAfter(myString, subSequence)}" />

<c:set var="variable" value="${fn:substringBefore(myString, subSequence)}" />

<c:set var="variable" value="${fn:toLowerCase(myString)}" />

<c:set var="variable" value="${fn:toUpperCase(myString)}" />

<c:set var="variable" value="${fn:trim(myString)}" />

În JavaServer Pages pot fi implementate etichete definite de utilizator, care în momentul transformării servlet-ului corespunzător sunt convertite în operaţiile specificate de clasa care îi este asociată, pentru ca atunci când se accesează pagina respectivă, acestea să fie executate. O clasă care defineşte funcţionalitatea unei anumite etichete trebuie să fie derivată din javax.servlet.jsp.tagtext.SimpleTagSupport, implementând metoda doTag(). Aceasta poate accesa obiectele din cadrul paginii JSP prin intermediul metodei getJSPContext(). De asemenea, în cazul în care în corpul etichetei se specifică anumită valoare, aceasta poate fi obţinută într-un obiect de tip StringWriter prin metoda getJspBody().invoke().

CustomTag.java

import java.io.*;
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.*;
 
public class CustomTag extends SimpleTagSupport {
 
    private String customAttribute;
    public void setCustomAttribute(String customAttribute) {
        this. customAttribute = customAttribute;
    }
    public String getCustomAttribute() {
        return customAttribute;
    }
 
    StringWriter stringWriter = new StringWriter();
    public void doTag() throws JspException, IOException {
        if (customAttribute != null) {
            // process tag attribute
            getJspContext().getOut().println(customAttribute);
        } else {
            // get the content from the tag body
            getJspBody().invoke(stringWriter);
            // process tag body’s content
            getJspContext().getOut().println(stringWriter.toString());
        }
    }
 
}

Clasa asociată etichetei definite de utilizator va trebui plasată la o locaţie vizibilă prin variabila de mediu CLASSPATH.

Asocierea dintre etichetă şi clasa asociată se face într-un fişier custom.tld care va fi plasat în webapps/root/WEB-INF al serverului web Apache Tomcat 8.x. Astfel, se va specifica numele etichetei (aşa cum va fi specificat în pagina JSP – elementul <name>, denumirea clasei care îi implementează funcţionalitatea (elementul <tag-class>) precum şi tipul de conţinut al corpului etichetei (elementul <body-content>, având ca valori posibile empty, dacă trebuie să fie vid, scriptless dacă este acceptat numai text static, expresii EL sau alte etichete şi tagdependent în cazul în care conţinutul este scris în alt limbaj, fiind interpretat de implementarea etichetei). De asemenea, pentru fiecare atribut trebuie indicate proprietăţile name (identificator unic al atributului în cadrul etichetei), required (care distinge între atributele obligatorii şi cele opţionale), rtexprvalue (care stabileşte validitatea valorii unei expresii definită în momentul rulării pentru atributul etichetei), type (care specifică tipul Java al atributului respectiv, implicit fiind java.lang.String), description şi fragment (care indică dacă valoarea asociată atributului va fi tratată ca un JspFragment).

<taglib>
    <tlib-version>1.0</tlib-version>
    <jsp-version>2.0</jsp-version>
    <short-name>A short description of my custom tag</short-name>
    <tag>
        <name>CustomTag</name>
        <tag-class>mypackage.CustomTag</tag-class>
        <body-content>scriptless</body-content>
        <attribute>
            <name>customAttribute</name>
            <required>true</true>
            <type>java.lang.Integer</type>
            <fragment>false</fragment>
        </attribute>
    </tag>
</taglib>

Pentru a putea fi folosită în cadrul unei pagini JSP, eticheta definită de utilizator trebuie declarată în acelaşi mod în care se procedează şi cu etichetele standard JSTL:

<%@ taglib prefix="customPrefix" uri="WEB-INF/custom.tld"%>

În momentul în care este utilizată, eticheta va avea numele definit în fişierul custom.tld, fiind prefixată cu denumirea indicată la declararea ei, precizând valori pentru toate atributele care au proprietatea required:

...
<customPrefix:CustomTag customAttribute="0">
    Some custom tag body
</customPrefix:CustomTag>
...

Potrivit implementării clasei asociate etichetei, efectul utilizării sale va fi afişarea valorii atributului specificat, în situaţia în care nu se decide realizarea altor tipuri de procesări asupra ei.

Se pot defini mai multe biblioteci de etichete definite de utilizator, grupate în funcţie de tipul de funcţionalitate pe care o pun la dispoziţia programatorilor, fiecare dintre acestea regăsindu-se într-un alt fişier şi utilizându-se un prefix diferit.

• aipi2014-lab08-eclipseee.zip (proiect EclipseEE )

• aipi2014-lab08-netbeans.zip (proiect NetBeans )

• aipi2014-lab08-noide.zip (proiect NoIDE - fără mediu integrat de dezvoltare)

1. [0 puncte] Să se instaleze baza de date prin rularea script-ului Laborator08.sql.

2. [0 puncte] În cazul Unix, daţi drepturi de execuţie tuturor fişierelor .sh din directorul bin al serverului Apache Tomcat, întrucât acestea sunt apelate la rândul lor de startup.sh, respectiv shutdown.sh.

aipi2014@ubuntu:~/apache-tomcat-8.0.15$ cd bin
aipi2014@ubuntu:~/apache-tomcat-8.0.15/bin$ sudo chmod +x *.sh

3. [0 puncte] Să se completeze în clasa Constants din pachetul ro.pub.cs.aipi.lab08.general valorile pentru utilizatorul şi parola pentru accesarea bazei de date.

4. [0 puncte]

Să se specifice variabilele de mediu JAVA_HOME şi JAVA_JRE în script-urile setClasspath[.bat|.sh] (din directorul bin al serverului Apache Tomcat).

Să se “publice” aplicaţia BookStore în contextul serverului Apache Tomcat prin rularea script-ului deploy[.bat|.sh] din directorul scripts.

Să se creeze o referinţă către serverul Apache Tomcat care să fie adăugată la proiectul BookStore.

Să se deschidă proiectul folosind opţiunea File → Import → General → Existing Project into Workspace...

Se accesează opţiunea Run as… → Run On Server din meniul contextual al aplicaţiei BookStore (right-click), bifându-se opţiunea Always use this server when running this project.

Să se creeze o referinţă către serverul Apache Tomcat care să fie adăugată la proiectul BookStore.

Se accesează opţiunea Deploy din meniul contextual al proiectului (accesat cu right-click).

5. [0 puncte] Să se testeze aplicaţia prin accesarea adresei http://localhost:8080/BookStore/.

6. [0 puncte] Să se acceseze pagina de administrator şi să se testeze funcţionalităţile implementate în cadrul acesteia (adăugare, editare, ştergere).

7. [10 puncte] În pagina client.jsp, să se construiască clauza WHERE a interogării corespunzătoare tabelei book, astfel încât conţinutul tabelei să fie filtrat după valoarea selectată din lista de colecţii / domenii.

SELECT ... FROM book
WHERE 
    series_id IN (SELECT id FROM series WHERE name='... ') 
    AND
    genre_id IN (SELECT id FROM genre WHERE name= '... ');

<c:set scope= "request" var= "myvar" value="${var1} some text ${var2}" />

8. [35 puncte] În pachetul ro.pub.cs.aipi.lab08.servlets, în clasa ClientServlet să se completeze metoda doPost() pentru a crea conţinutul coşului de cumpărături, ţinând cont de situaţia în care pentru un produs care există deja în coşul de cumpărături se poate actualiza cantitatea.

În situaţia în care solicitarea pentru un produs depăşeşte stocul existent, aceasta nu va fi luată în considerare, afişându-se un mesaj de eroare.

Dacă un produs există deja în coşul de cumpărături, valoarea respectivă va fi suprascrisă. Dacă valoarea este 0, produsul va fi şters din coşul de cumpărături.

9. [15 puncte] În pagina client.jsp, să se afişeze conţinutul coşului de cumpărături.

În coşul de cumpărături se va afişa numărul de exemplare comandate, titlul cărţii, editura şi anul, precum şi suma pentru fiecare produs în parte, respectiv preţul total pentru întreg coşul de cumpărături.

10. [10 puncte] În pagina client.jsp să se să se adauge două butoane prin care se poate anula, respectiv finaliza o comandă (o comandă conţine produsele selectate în coşul de cumpărături).

11. [40 puncte] În pachetul ro.pub.cs.aipi.lab08.servlets, în clasa ClientServlet, metoda doPost(), să se implementeze operaţia pentru anularea, respectiv finalizarea unei comenzi.

session.setAttribute(Utilities.removeSpaces(Constants.SHOPPING_CART.toLowerCase()), shoppingCart);

12. [10 puncte] Să se implementeze operaţia de deautentificare printr-un buton plasat sub mesajul de întâmpinare pentru fiecare utilizator în pagina de tip client. În această situație, utilizatorul se va întoarce în pagina de autentificare (login.jsp).

Eric Jendrock, Ricardo Cervera- Navarro, Ian Evans, Kim Haase, William Markito - The Java EE 7 Tutorial - capitolul 9
Apache Tomcat
Basic JSP Tutorial
Knowledge Base on JSP
JSP Tutorial
JSP Tutorial
JavaServer Pages Tutorial
Building Web Apps in Java: Beginning & Intermediate Servlet & JSP Tutorials
Advanced Servlet and JSP Tutorials
Java web development with Eclipse WTP - Tutorial
Giulio Zambon with Michael Sekler – Beginning JSPTM, JSFTM and Tomcat Web Development: From Novice to Professional, Apress, 2007
Irina ATHANASIU, Java ca limbaj pentru programare distribuita, Editura Matrix Rom, București, 2002

Proiect EclipseEE
Proiect NetBeans