• descrierea tipurilor de aplicații web ce pot fi implementate folosind Java Enterprise Edition și a modului în care sunt gestionate cererile și răspunsurile interschimbate între client și server;
• înțelegerea arhitecturii serverului HTTP Apache Tomcat, a funcționalității pe care o pune la dispoziție și a modului în care pot fi dezvoltate aplicații web ce folosesc tehnologia Java Servlets în contextul său;
• proiectarea de aplicații web pe baza Java Servlets, prin realizarea operațiilor corespunzătoare ciclului de viață (inițializare, execuție, distrugere);
• dezvoltarea de aplicații web ce utilizează tehnologia Java Servlets folosind medii integrate de dezvoltare (Eclipse / NetBeans);
• implementarea unor funcționalități complexe ale aplicațiilor web, conform specificațiilor funcționale (filtre, invocarea altor resurse web, încărcarea de fișiere, procesare asincronă, operații I/O non-blocante);
• integrarea aplicațiilor web cu sisteme de gestiune pentru baze de date pentru asigurarea persistenței informațiilor;
• gestionarea stării aplicației web folosind diferite mecanisme (câmpuri ascunse, rescrierea URL-urilor, cookies, sesiuni).

Java Servlets, Apache Tomcat 8.x, web application, Java Enterprise Edition, request, response, servlet life cycle, servlet execution flow, filter / filter chain, request dispatcher, file upload, asynchronous processing, non-blocking I/O, DBMS integration, hidden fields, URL rewriting, cookie, session

TODO

O aplicaţie web este definită ca o extensie dinamică a unui server (web sau de aplicaţii).

Frecvent, acestea sunt clasificate ca:

1. orientate pe prezentare, în cazul în care sunt generate pagini Internet interactive descrise folosind diferite limbaje de adnotare (HTML, XML) având conţinut dinamic ca răspuns la cererile formulate de utilizatori; pentru acest tip de servicii se utilizează de obicei tehnologiile Facelets sau JavaServer Faces;
2. orientate pe servicii, în situaţia în care implementează funcţionalitatea unui serviciu web; tehnologia Java Servlets este mai adecvată dezvoltării acestui tip de aplicaţii web, fiind totodată utilizată şi pentru gestiunea datelor nontextuale şi a mecanismelor de control a altor tipuri de aplicaţii web.

De cele mai multe ori, o aplicaţie web orientată pe prezentare exploatează funcţionalitatea unei aplicaţii web orientată pe servicii.

În Java Enterprise Edition, o astfel de funcţionalitate este implementată prin componente web, acestea putând fi Java Servlets, pagini Internet dezvoltate cu tehnologiile JSF (JavaServer Faces) / JSP (Java Server Pages), respectiv servicii web (implementate cu JAX-WS sau JAX-RS). Capabilităţile componentelor web sunt îmbogăţite prin serviciile pe care le oferă containerul în contextul căruia rulează, cum ar fi gestiunea cererilor, securitate, concurenţă şi gestiunea ciclului de viaţă, oferind acces la interfeţe de programare ca posibilitatea accesării lor prin intermediul unei denumiri, poştă electronică, tranzacţii.

Pe lângă acestea, aplicaţia web conţine resurse statice (imagini, foi de stil), clase ajutătoare sau diferite biblioteci.

Cererile HTTP formulate de clienţi şi transmise prin intermediul unui browser sunt convertite de serverul web (ce implementează tehnologiile Java Servlet şi JavaServer Pages) într-un obiect HttpServletRequest, fiind ulterior transmis componentei web ce poate interacționa cu o clasă JavaBeans sau cu o bază de date pentru a genera conţinutul dinamic. Răspunsul obţinut poate fi transmis altei componente web sau va fi convertit într-un obiect HttpServletResponse, fiind apoi transformat într-un răspuns HTTP care este afişat mai departe în browser.

Unele aspecte ale comportamentului aplicaţiilor web pot fi configurate atunci când aceasta este instalată (eng. deploy) în contextul container-ului fie prin intermediul unor adnotări Java, fie în fişiere XML (descriptorul de instalare al aplicaţiei web) care trebuie să respecte schemele specificaţiei Java Servlet.

Tehnologia Java Servlets furnizează un mecanism prin care pot fi dezvoltate aplicaţii web folosind limbajul de programare Java, reprezentând o alternativă pentru CGI (Common Gateway Interface), caracterizată prin dependența de platformă (programele fiind scrise în C) și lipsă de scalabilitate (performanțe scăzute în contextul în care trebuiau oferite răspunsuri pentru mai multe cereri transmise simultan). Aceste inconveniente au fost adresate în mod deosebit în cadrul tehnologiei Java Servlets.

Avantajele utilizării Java Servlets includ:

• eficienţa (iniţializarea se face doar la încărcarea unui servlet, cererile fiind tratate prin apelarea metodei service());
• persistenţa (după ce este încărcat, obiectele unui servlet – ce pot conţine informaţii din baza de date – sunt disponibile cât timp acesta este în execuţie, ceea ce asigură o performanţă ridicată comparativ cu încărcarea din baza de date a informaţiilor fiecare dată);
• portabilitate (asigurată de limbajul de programare Java, astfel încât platforma pe care rulează aplicaţia poate fi schimbată fără modificarea codului sursă);
• robusteţe (acces la toate mecanismele oferite de limbajul de programare Java – cu o ierarhie de excepţii pentru tratarea erorilor şi colectarea memoriei disponibile);
• extensibilitate (fiind dezvoltat într-un limbaj orientat obiect, un servlet poate fi extins potrivit cerinţelor aplicaţiei);
• securitate (conform modelului de securitate implementat în Java).

Un servlet reprezintă o clasă implementată în limbajul de programare Java, utilizată pentru a extinde capabilităţile unui server care găzduieşte aplicaţii accesate conform modelului cerere-răspuns. Cea mai frecvent întâlnită funcţionalitate în legătură cu un servlet este legată de aplicaţiile web, cu toate că acesta poate răspunde oricărui tip de cereri. Prin urmare tehnologia Java Servlet defineşte clase servlet adaptate protocolului HTTP.

Pachetele javax.servlet şi javax.servlet.http oferă interfeţe şi clase pentru scrierea de Java Servlets. Orice servlet trebuie să implementeze interfaţa javax.servlet.Servlet care defineşte metodele ce caracterizează ciclul de viaţă al unui astfel de obiect. Când este implementat un serviciu generic, se poate folosi (sau extinde) clasa javax.servlet.GenericServlet. Clasa javax.servlet.http.HttpServlet oferă metode precum doGet() şi doPost() pentru a trata servicii specifice protocolului HTTP.

Ciclul de viaţă al unui Java Servlet este controlat de containerul în care a fost configurat servlet-ul. Atunci când o cerere este asociată unui servlet, container-ul care conţine servlet-ul realizează următoarele acţiuni:

1. dacă nu există o instanţă a servlet-ului:
   1. încarcă clasa servlet;
   2. creează o instanţă a clasei servlet;
   3. iniţializează instanţa clasei servlet prin apelarea metodei init();
2. apelează metoda service() având ca parametrii obiecte cerere şi răspuns.

În condiţiile în care este necesară ştergerea servlet-ului, este apelată metoda destroy() a acestuia.

Se pot defini clase ascultător (implementări ale unor interfeţe ascultător), adnotate cu însemnarea @WebListener spre a monitoriza evenimente corespunzătoare ciclului de viaţă al unui obiect Java Servlet. Metodele asociate vor primi ca argumente parametrii ce conţin informaţii referitoare la evenimentul respectiv.

Un Java Servlet este o clasă derivată din javax.servlet.http.HttpServlet, suprascriind metodele init(), destroy() (pentru operaţiile realizate la construirea şi distrugerea obiectului instanţă a clasei), respectiv (cel mai frecvent) doPost() şi doGet() pentru gestiunea interacţiunii cu utilizatorul (astfel de operații fiind utile mai ales atunci când se folosesc formulare, astfel încât comunicaţia dintre server şi client transmite informaţii prin intermediul acestora).

SampleServlet.java

import java.io.IOException;
import java.io.PrintWriter;
import java.util.ArrayList;
import java.util.Enumeration;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
 
@WebServlet("/SampleServlet")
public class SampleServlet extends HttpServlet {
  final public static long serialVersionUID = 1024L;
 
  @Override
  public void init(ServletConfig config) throws ServletException {
    super.init(config);
  }
 
  @Override
  public void destroy() {
  }      
 
  @Override
  public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    ArrayList<String> values = new ArrayList<>();
    Enumeration parameters = request.getParameterNames();     
    while(parameters.hasMoreElements()) {
      String parameter = (String)parameters.nextElement();
      if (parameter.contains("...")) {
        values.add(request.getParameter(parameter)));
      }
    }
    response.setContentType("text/html");        
    PrintWriter printWriter = new PrintWriter(response.getWriter());     
    displayPage(printWriter);
    printWriter.close();
  }
 
  @Override
  public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    // ...
  }      	 
}

Adnotarea @WebServlet defineşte clasa Java Servlet într-o aplicaţie web, conţinând metadate despre aceasta. Ea trebuie să specifice cel puţin un URL (prin câmpurile urlPatterns sau value), celelalte atribute fiind opţionale, iniţializându-se cu valorile implicite.

Container-ul iniţializează un obiect Java Servlet (apelând metoda init()) după ce îl încarcă şi îl instanţiază, dar înainte de a accepta invocări de la clienţi. Se permite astfel încărcarea de informaţii persistente (date de configurare), iniţializarea resurselor şi realizarea de operaţii care sunt executate o singură dată. Alternativ se poate folosi atributul initParams al adnotării @WebServlet ce conţine la rândul său o adnotare @WebInitParam.

Procesul de iniţializare permite obţinerea de informaţii care sunt utile doar obiectului servlet în cauză. Pentru obţinerea de date care sunt disponibile tuturor componentelor aplicaţiei web sunt folosiţi parametrii ai contextului. Cel mai frecvent, în cadrul acestui proces este realizată conexiunea către sistemul de gestiune al bazei de date.

În situaţia în care nu se reuşeşte terminarea cu succes a operaţiei de iniţializare, este generată o excepţie de tipul UnavailableException.

Funcţionalitatea pusă la dispoziţie de către un servlet este implementată în metoda service() a clasei GenericServlet, prin apelarea metodelor corespunzătoare doMethod() (unde Method poate avea valorile Get, Post, Put, Delete, Options sau Trace) ale unui obiect HttpServlet sau prin metode specifice protocolului definite de o clasă care implementează interfaţa Servlet. O metodă serviciu va primi informaţiile din cerere (obiect tip HttpServletRequest) apelând getParameterNames() / getParameter() şi va transmite informaţiile în răspuns (obiect tip HttpServletResponse) – folosind un obiect PrintWriter asociat acestuia (obţinut prin metoda getWriter()).

public abstract class HttpServlet extends GenericServlet implements java.io.Serializable

Prin urmare, orice clasă derivată din HttpServlet trebuie să implementeze cel puţin una dintre metodele:

• doGet(), dacă servlet-ul tratează cereri HTTP GET;
• doPost(), dacă servlet-ul tratează cereri HTTP POST;
• doPut(), dacă servlet-ul tratează cereri HTTP PUT;
• doDelete(), dacă servlet-ul tratează cereri HTTP DELETE;

De regulă, metodele doOptions() şi doTrace() sunt mai puţin utilizate.

Totodată, este recomandat să se implementeze şi metodele:

• init() şi destroy(), pentru a gestiona resursele alocate în timpul în care servlet-ul este în execuţie;

• getServletInfo(), folosit de servlet pentru a oferi informaţii despre el.

O cerere conţine datele transmise de la client către servlet şi trebuie să implementeze interfaţa javax.servlet.ServletRequest, unde sunt definite metode pentru accesarea de:

• parametri (pentru comunicarea de informaţii între clienţi / servleţi);
• atribute – instanţe ale unor obiecte (folosite la comunicarea dintre un container al unui servlet şi servlet sau pentru comunicarea între mai mulţi servleţi);
• informaţii despre:
  • protocolul prin care este transmisă cererea;
  • locaţie.

Obiectul javax.servlet.http.HttpServletRequest transmis prin cerere conţine URL-ul cererii, antetele HTTP şi interogarea formată din perechi de parametri şi valori.

Obiectul HttpServletRequest conţine atât denumirile parametrilor transmişi (metoda getParameterNames()) cât şi valoarea lor (metoda getParameter() ce primeşte ca argument identificatorul acestuia).

Metodele mai folosite ale clasei HttpServletRequest sunt moștenite din clasa ServletRequest: getContentType(), getInputStream(), getParameter(), getParameterNames(), dar și proprii: getCookies(), getHeaderNames(), getHeaders(), getSession(), getMethod().

Un răspuns conţine datele transmise de la servlet către client şi trebuie să implementeze interfaţa javax.servlet.ServletResponse, unde sunt definite metode pentru obţinerea unui flux prin care se poate realiza comunicarea cu clientul, indicându-se tipul de conţinut (prin metoda setContentType(), al cărei parametru poate fi text/html), dacă se aloca o zonă de memorie (metoda setBufferSize() oferă o perioadă timp înainte ca mesajul să fie transmis la client, permiţând stabilirea unor coduri de stare sau a unor antete) şi informaţii despre locaţie.

Obiectul HttpServletResponse are câmpuri care reprezintă antete HTTP ce conţin coduri de stare (pentru a indica motivele pentru care o cerere nu poate fi satisfăcută sau faptul că s-a realizat redirecţionarea către altă resursă) ca şi obiecte ce vor reţine informaţii specifice aplicaţiei (eventual, legate de sesiune) – eng. cookies, pe maşina clientului astfel încât persistenţa stării este realizată prin mecanisme implementate în afara serverului. Un astfel de mecanism este necesar datorită faptului că serverul nu dispune de alte posibilităţi pentru a identifica un client, în interacţiunea cu aplicaţia web pe care o găzduieşte.

Obiectul javax.servlet.http.HttpServletResponse este folosit pentru construirea documentului care va transmis de la server către client, într-un obiect de tip PrintWriter.

Metodele cele mai folosite din clasa HttpServletResponse sunt moştenite din clasa ServletResponse: flushBuffer(), getBufferSize(), setBufferSize(), getContentType(), setContentType(), getOutputStream(), setCharacterEncoding(), dar şi proprii: addCookie(), getHeader(), setHeader(), getStatus(), setStatus().

Un container ce conţine un servlet poate determina distrugerea acestuia (în cazul în care se realizează colectarea memoriei disponibile sau atunci când acesta se închide), apelându-se metoda destroy() din interfaţa Servlet. Aici toate resursele utilizate de către servlet trebuie eliberate, asigurându-se şi persistenţa prin reţinerea informaţiilor necesare în baza de date. Toate metodele serviciu corespunzătoare unui servlet trebuie să fie terminate atunci când container-ul urmează să îl distrugă. Astfel, metoda destroy() este apelată doar după ce toate metodele serviciu s-au terminat sau după expirarea unei anumite perioade stabilită de server. Trebuie ca toate firele de execuţie pe care sunt realizate operaţii de către server să se termine atunci când este apelată metoda destroy().

În exemplu, au fost preluaţi parametrii transmişi printr-un apel tip POST (presupunând că parametrii au fost specificaţi la crearea unui formular prin elemente de tip <input> - care nu au activat parametrul disabled, acestea nefiind transmise) şi reţinuţi în tabloul values, de unde pot fi prelucraţi. De asemenea, construirea răspunsului către client se face în metoda displayPage(), care primeşte un obiect de tip PrinterWriter în care se creează (prin apeluri println()) pagina Internet care va fi afişată în browser.

Un filtru este un obiect care poate transforma antetele şi/sau conţinutul unei cereri sau a unui răspuns. Funcţionalitatea sa poate fi ataşată oricărui tip de resursă web şi constă în:

• analiza unei cereri şi realizarea unor acțiuni în conformitate cu aceasta;
• blocarea unei cereri şi a răspunsului corespunzător pentru a fi prelucrate mai departe;
• modificarea antetelor şi/sau conţinutului unei cereri/răspuns, construind o versiune particularizată a acesteia;
• interacţiunea cu resurse externe.

De regulă, filtrele sunt folosite în procesul de autentificare, jurnalizare, conversie de imagini, compresie a datelor, criptare, parsarea fluxurilor de date, transformări XML. O resursă web poate fi filtrată printr-un lanţ ce conţine 0, 1 sau mai multe filtre într-o anumită ordine.

În pachetul javax.servlet, filtrele sunt definite prin interfeţele Filter, FilterChain şi FilterConfig.

Un filtru implementează interfaţa javax.servlet.Filter şi este adnotat cu însemnarea @WebFilter care trebuie să specifice cel puţin un URL (folosind atributele urlPatterns sau value. Informaţiile cu privire la configurarea unui filtru sunt precizate prin atributul initParams al aceleiaşi adnotări. Metoda cea mai importantă a unui filtru este doFilter() care primeşte cererea, răspunsul şi lanţul de filtre, în afară de ea trebuind implementate metodele init() şi destroy(). Metoda doFilter() poate analiza antetele cererii şi răspunsului (doar după invocarea următorului filtru din lanţul de filtre), poate particulariza obiectele cerere şi răspuns în sensul modificării antetelor sau conţinutului, poate invoca următorul filtru din lanţul de filtre (prin apelarea metodei doFilter() a acestuia şi transmiterea cererii şi răspunsului primite sau prelucrate de el), respectiv blocarea comunicaţiei, generarea unei excepţii pentru a indica producerea unei erori în cadrul procesării.

Un filtru poate adăuga un atribut la cerere sau poate introduce informaţii în contextul unui răspuns. Pentru a suprascrie metodele cererii, obiectul de tip cerere va fi împachetat într-un obiect derivat din ServletRequestWrapper sau HttpServletRequestWrapper. Similar, pentru răspuns va fi folosit ServletResponseWrapper sau HttpServletResponseWrapper.

Un container foloseşte asocieri între filtre şi resurse web (prin nume sau prin URL) pentru a determina modul (precum şi ordinea) în care vor fi aplicate. În scopuri de jurnalizare, poate fi folosită masca /*, aplicându-se tuturor evenimentelor ce implică comunicaţie între client şi server. Un filtru poate fi asociat mai multor resurse web şi o resursă web poate avea asociate mai multe filtre (un lanţ de filtre).

Invocarea altor resurse web poate fi realizată:

• direct, incluzând conţinutul altei resurse sau transmiţând mai departe cererea către o altă resursă;
• indirect, încorporând un URL care referă o altă componentă web în răspunsul transmis către client.

Pentru a invoca o resursă disponibilă pe serverul pe care rulează componenta web, trebuie obţinut un obiect RequestDispatcher folosindu-se metoda getRequestDispatcher() (ce primeşte ca parametru URL-ul resursei ce va fi invocată) aplicată fie pe obiectul cerere, fie pe contextul web. URL-ul resursei va fi o cale relativă, în situaţia în care se apelează din contextul cererii, respectiv o cale absolută, în cazul în care se apelează pe contextul web. În cazul în care resursa nu este disponibilă pe server sau serverul nu implementează un obiect RequestDispatcher pentru tipul respectiv de resursă, metoda getRequestDispatcher() va întoarce null.

Includerea unei alte resurse web (header, footer, informaţii de copyright, meniuri) în răspunsul construit de o componentă web se face folosind metoda include() a obiectului RequestDispatcher. Dacă resursa este o componentă web, aceasta va fi executată (primind cererea) şi rezultatul acestei operaţii integrat în răspuns. Resursa web inclusă va avea acces la obiectul cerere, însă va fi limitată în privinţa obiectului răspuns în sensul că poate modifica conţinutul acestuia dar nu şi antetele sale (ca atare, nu poate apela metodele care modifică antetele obiectului răspuns).

Pentru transmiterea mai departe a cererii către o altă resursă pentru a realiza alte procesări şi a genera răspunsul, se foloseşte metoda forward() a obiectului RequestDispatcher. URL-ul cererii va fi modificat la cel al paginii care va realiza prelucrarea ei. De asemenea, se reţine şi URI-ul original şi parţile sale componente ca atribute ale cererii. Responsabilitatea răspunsului îi revine resursei către care a fost transmis răspunsul. O astfel de funcţionalitate este însă limitată în cazul în care au fost folosite obiecte ServletOutputStream sau PrintWriter în cadrul servletului, generându-se în caz contrar excepţii de tipul IllegalStateException.

Transmiterea controlului către obiectele Java Servlet asociate tipurilor de utilizatori autentificate în sistem se poate realiza astfel:

RequestDispatcher dispatcher = null;
switch(getUserType(username, password)) {
  case Constants.USER_TYPE_ADMINISTRATOR:
    dispatcher = getServletContext().getRequestDispatcher("/" + Constants.ADMINISTRATOR_SERVLET_CONTEXT);
    break;
  case Constants.USER_TYPE_CLIENT:
    dispatcher = getServletContext().getRequestDispatcher("/" + Constants.CLIENT_SERVLET_CONTEXT);
    break;
}
if (dispatcher != null) {
  dispatcher.forward(request,response);
}

Accesarea contextului web în care sunt executate componentele se face prin metoda getServletContext() care întoarce un obiect de tipul ServletContext, prin intermediul căruia pot fi accesaţi parametrii de iniţializare, resurse asociate cu contextul web, atribute având tipuri de obiecte asociate şi capabilităţi legate de jurnalizare.

Una dintre funcţionalităţile cele mai frecvent implementate în cazul unei aplicaţii web o reprezintă încărcarea de fişiere. În acest scop, adnotarea @MultipartConfig este folosită pentru a indica faptul că servletul pentru care este declarată poate prelucra cereri folosind tipul MIME multipart/form-date, componentele javax.servlet.Part putând fi obţinute prin una din metodele request.getPart(String name) sau request.getParts(). Adnotarea @MultipartConfig suportă mai multe atribute opţionale:

• location – reprezintă calea absolută spre un director din sistemul de fişiere; nu sunt suportate căi relative la contextul aplicaţiei web; de regulă, locaţia este folosită pentru a stoca fişiere temporare în timp ce părţile fişierului sunt procesate sau atunci când dimensiunea fişierului depăşeşte valoarea sprecificată de proprietatea fieldSizeThreshold; valoarea implicită este “”;
• fieldSizeThreshold – dimensiunea fişierului (în octeţi) după care acesta va fi stocat temporar pe disc; valoarea implicită este 0 octeţi;
• maxFileSize – dimensiunea maximă permisă pentru încărcarea de fişiere, exprimată în octeţi; în situaţia în care se încearcă încărcarea de fişiere care depăşesc această valoare, se generează o excepţie de tipul IllegalStateException; valoarea implicită este nelimitată;
• maxRequestSize – dimensiunea maximă pentru o cerere multipart/form-date, exprimată în octeţi; containerul va genera o excepţie dacă valoarea totală a tuturor fişierelor încărcate depăşeşte acest prag; valoarea implicită este de asemenea nelimitată.

Alternativ, aceste proprietăţi pot fi specificate în fişierul de configurare web.xml, în cadrul secţiunii <multipart-config> … </multipart-config>, denumirile câmpurilor fiind identice cu cele ale proprietăţilor adnotării.

Specificaţia Java Servlet defineşte pentru un obiect HttpServletRequest:

• Collection<Part> getParts() – în cazul în care sunt încărcate fişiere având tipuri diferite; poate fi folosit un obiect Iterator spre a fi parcurse părţile;
• Part getPart(String name) – poate fi folosit pentru a obţine o parte identificată printr-un nume.

Interfaţa javax.servlet.http.Part oferă metode pentru analiza fiecărei părţi cu privire la nume, dimensiune, tipul de conţinut, procesarea antetelor transmise împreună cu partea respectivă, salvarea pe disc (prin intermediul metodei write(String filename)) sau ştergerea ei.

Containerele asociază câte un fir de execuţie pentru fiecare cerere provenită de la client. În condiţii de încărcare foarte mare, este necesar un număr corespunzător de fire de execuţie, situaţie în care se poate ajunge la depăşirea memoriei disponibile sau a numărului de fire de execuţie. Scalabilitatea aplicaţiilor se obţine asigurându-se faptul că nici un fir de execuţie nu rămâne nefolosit (cu alte cuvinte, că nu sunt blocate în aşteptarea unor resurse), astfel încât să poată fi utilizat pentru alte cereri. În aceste cazuri procesarea asincronă presupune crearea unui fir de execuţie pentru fiecare operaţie blocantă şi eliberarea firelor de execuţie ocupate.

Dacă în procesul de tratare a unei cereri un servlet întâlneşte o operaţie care ar putea fi blocantă, aceasta poate fi delegată către un context de execuţie asincron cu eliberarea firului de execuţie ocupat către container, fără a se genera un răspuns. În momentul în care operaţia în cauză se termină, va putea fi generat şi răspunsul aferent cererii fie din contextul de execuţie asincron, fie din contextul altui servlet către care este transmis mai departe.

Pentru a permite procesarea asincronă a unui servlet, trebuie specificată proprietatea asyncSupported avand valoarea true în cadrul adnotării @WebServlet. Funcţionalitatea pentru a realiza aceste operaţii este oferită de clasa javax.servlet.AsyncContext, un obiect de acest tip putând fi obţinut în metoda service() din obiectul cerere:

public void service(HttpServletRequest request, HttpServletResponse response) {
  // ...
  AsyncContext asyncContext = request.startAsync();
  // ...
}

Astfel, cererea este transferată într-un context asincron, astfel încât răspunsul nu va fi transmis la ieşirea din metoda service(). El va trebui generat în contextul asincron după terminarea operaţiei blocante sau se transmite cererea mai departe către un alt servlet.

Metodele definite de clasa AsyncContext sunt:

• void start(Runnable run) – containerul oferă un alt fir de execuţie unde operaţia blocantă poate fi procesată; codul care tratează această prelucrare trebuie specificat în clasa care implementează interfaţa Runnable; o asfel de clasă poate fi definită ca internă atunci când se apelează metoda start() sau se poate folosi alt mecanism pentru a transmite clasei instanţa AsyncContext;
• ServletRequest getRequest() – întoarce cererea folosită pentru a iniţializa contextul asincron; metoda poate fi folosită spre a obţine parametrii cererii în cadrul contextului asincron;
• ServletResponse getResponse() – întoarce răspunsul utilizat spre a iniţializa contextul asincron; metoda poate fi folosită pentru a construi un răspuns cu rezultatele operaţiei blocante;
• void complete() – termină operaţia asincronă şi transmite răspunsul asociat cu contextul asincron; poate fi apelată după constuirea răspunsului;
• void dispatch(String path) – transmite obiectele cerere şi răspuns către calea indicată; metoda este folosită pentru a delega altui servlet responsabilitatea cu privire la aceste obiecte, după terminarea operaţiei.

Un exemplu de utilizare al acestei funcţionalităţi ar putea fi:

@WebServlet(urlPatterns={"/AsyncServlet"}, asyncSupported=true)
public class AsyncServlet extends HttpServlet {
  @Override
  public void service(HttpServletRequest request, HttpServletResponse response) {
    response.setContentType("text/html");
    final AsyncContext asyncContext = request.startAsync();
    asyncContext.start(new Runnable() {
      public void run() {
        HttpServletRequest request = asyncContext.getRequest();
        String value = request.getParameter(attribute);
        HttpServletResponse response = asyncContext.getResponse();
        response.getWriter().println(blockingOperation(value));
        asyncContext.complete();
      }
    });
  }
}

Prin proprietatea asyncSupported=true se specifică faptul că servletul are capacitatea de a realiza procesare asincronă. Metoda request.startAsync() determină procesarea asincronă a cererii, astfel încât răspunsul să nu fie transmis către client la sfârşitul metodei service(). Metoda startAsync() se întoarce imediat, iar cererea este procesată în cadrul contextului asincron. Apelul asyncContext.start(…) creează un nou fir de execuţie în container. Codul metodei run() a clasei interne se execută în noul fir de execuţie, însă are acces la obiectele cerere şi răspuns ale contextului din care a fost apelată. Metoda complete() transmite răspunsul către client.

În situaţia în care operaţiile de intrare/ieşire se desfăşoară mai rapid pe server decât pe client (datorită limitărilor introduse de comunicaţia prin reţeaua de calculatoare), se pot folosi operaţii de intrare/ieşire non-blocante asociate cu procesarea asincronă pentru a se asigura eliminarea timpilor morţi din firele de execuţie. Astfel, fluxurilor de intrare/ieşire li se vor asocia mai multe obiecte ascultător, iar operaţiile de citire/scriere se vor realiza în metodele care tratează aceste evenimente.

Clasa javax.servlet.ServletInputStream suportă metoda void setReadListener(ReadListener rl) care asociază un obiect ascultător fluxului de intrare care conţine metode pentru a citi date asincron. Acesta este creat ca o clasă internă sau se foloseşte alt mecanism pentru a transmite fluxul de intrare obiectului ascultător.

Metodele de tratare a evenimentelor asociate unui obiect ReadListener sunt void onDataAvailable(), void onAllDataRead(), void onError(Throwable t).

• boolean isReady() – întoarce true dacă datele pot fi citite non-blocant;
• boolean isFinished() – întoarce true când toate datele au fost citite.

Clasa javax.servlet.ServletOutputStream suportă metodele:

• void setWriteListener(WriteListener wl) – asociază un obiect ascultător fluxului de ieşire care conţine metode pentru a scrie date asincron; acesta este creat ca o clasă internă sau se foloseşte alt mecanism pentru a transmite fluxul de intrare obiectului ascultător;
• boolean isReady() – întoarce true dacă datele pot fi scrise non-blocant.

Metodele de tratare a evenimentelor asociate unui obiect WriteListener sunt void onWritePossible(), void onError(Throwable t).

Ca în orice aplicaţie Java, accesul la baza de date se face folosind metodele puse la dispoziţie prin API-ul JDBC (pachetul java.sql), biblioteca ce conţine “driver”-ul de conectare.

Modificările care se impun în cazul unei aplicaţii Internet sunt nesemnificative, clasele dezvoltate pentru subnivelul de acces la date (utilizate pentru aplicaţii desktop) putând fi refolosite în acest caz spre a genera conţinutul dinamic obţinut din baza de date, fără a fi necesară instalarea de utilitare pe client, informaţiile fiind vizualizate prin intermediul browser-ului.

Încărcarea “driver”-ului de conectare trebuie să se realizeze explicit, prin intermediul metodei Class.forName(“com.mysql.jdbc.Driver”); înainte de apelarea oricărei funcționalități oferite de API-ul JDBC întrucât această operație nu este realizată de serverul Apache Tomcat. De asemenea, este invocată în mod automat metoda DriverManager.registerDriver() primind ca parametru instanța obținută, astfel încât acesta să fie inclus în lista de “drivere” disponibile pentru obținerea de conexiuni.

try {
  Class.forName("com.mysql.jdbc.Driver");
} catch(ClassNotFoundException exception) {
  System.out.println("An exception has occurred: " + exception.getMessage());
  if(Constants.DEBUG) {
    exception.printStackTrace();
  }
}

Protocolul HTTP este un protocol fără stare fiind caracterizat prin cereri şi răspunsuri ca tranzacţii izolate.

Problema apare în momentul când trebuie să se coreleze mai multe accesări (care provin de la acelaşi utilizator).

Soluţiile pentru rezolvarea acestui inconvenient implică:

1. utilizarea de câmpuri ascunse;
2. rescrierea URL-urilor pentru a include parametrii suplimentari;
3. utilizarea de cookie-uri;
4. folosirea unor instrumente de “urmărire” a sesiunii.

Câmpurile ascunse pot fi conţinute în formularele din paginile HTML (elemente de tip <INPUT type=“hidden” …>), dar au dezavantajul că pot fi identificate cu uşurinţă prin inspectarea codului sursă.

Rescrierea URL-urilor presupune adăugarea unei (aceleiaşi) informaţii la URL-urile paginilor care sunt transmise utilizatorului, informaţia fiind primită automat de server pentru cererile din pagina respectivă. Această metodă se foloseşte împreună cu protocolul HTTP GET.

Ambele soluţii presupun generarea dinamică a paginilor ca şi includerea unui formular.

Cookie-urile sunt fişiere care conţin perechi de tipul (cheie, valoare), fiind create de server şi incluse ca instrucţiuni în antetul mesajului HTTP transmis ca răspuns.

În pachetul javax.servlet.http este definită clasa Cookie:

public class Cookie extends java.lang.Object implements java.lang.Cloneable, java.io.Serializable

având un constructor care primeşte două şiruri de caractere reprezentând cheia, respectiv valoarea.

Pentru un obiect de tip Cookie se pot gestiona denumirea (getName()), valoarea (getValue(), setValue()), timpul de expirare (getMaxAge(), setMaxAge()), domeniul (getDomain(), setDomain()) sau calea (getPath(), setPath()).

Obiectul cookie poate fi inclus într-un obiect de tip HttpServletResponse, prin intermediul metodei addCookie():

response.addCookie(cookie);

Cookie-urile pot fi obţinute prin metoda getCookies() implementată în clasa HttpServletRequest.

Cookie[] cookies = request.getCookies();

În pachetul javax.servlet.http este definită şi interfaţa HttpSession, care crează un singur obiect pentru o sesiune, putând stabili anumite valori pentru identificarea conexiunii dintre client şi server, legătura fiind realizată prin cookie (dacă sunt acceptate de client) sau rescrierea URL-urilor.

HttpSession session = request.getSession(true);

Metoda getSession() întoarce sesiunea asociată unei cereri, sau dacă nu există o sesiune asociată cererii, aceasta este creată, dacă nu se specifică astfel. Metoda getSession() poate fi apelată şi fără parametri: getSession() = getSession(true).

Atribute ce pot reţine diferite obiecte sunt asociate unei sesiuni prin intermediul unei denumiri. Acestea sunt accesibile oricărei componente web care aparţine contextului respectiv şi tratează cereri care fac parte din aceeaşi sesiune. Ele pot fi notificate cu privire la producerea evenimentelor legate de asocierea lor cu o sesiune sau chiar de sesiunea in cauză. Astfel, clasele ascultător vor implementa interfaţa javax.servlet.http.HttpSessionBindingListenerInterface pentru a monitoriza asocierea sau disocierea unui obiect cu o sesiune, respectiv interfaţa javax.servlet.http.HttpSessionActivationListener spre a se detecta momentul când sesiunea este activată sau pasivizată (la transferul între maşini virtuale, respectiv la încărcarea / descărcarea dintr-un depozit persistent).

Obţinerea atributelor este realizată prin metodele getAttributeNames(), respectiv getAttribute(String), iar stabilirea lor prin metoda setAttribute(String, Object). Totodată, un atribut poate fi eliminat prin metoda removeAttribute(String). Alternativ, un atribut poate fi reiniţializat (având conţinut vid) şi retransmis sub această formă prin aceasta reţinându-se o anumită stare a aplicaţiei.

Întrucât un client HTTP nu poate specifica momentul în care sesiunea nu mai este necesară, este asociat un timp de expirare (prin metodele getMaxInactiveInterval(), setMaxInactiveInterval()), astfel încât resursele utilizate de sesiune să poată fi refolosite. O sesiune nu va expira în cazul în care este accesată periodic (frecvenţa fiind mai mare decât timpul de expirare) – prin metodele serviciu care iniţializează (din nou) perioada în care sesiunea poate fi utilizată. Totodată, atunci când interacţiunea cu un client HTTP este încheiată, se poate folosi metoda invalidate() pentru a distruge sesiunea eliberând resursele folosite.

Asocierea unei sesiuni cu un utilizator implică de regulă transmiterea unui identificator între client şi server. Acesta poate fi reţinut pe client sub formă de cookie sau poate fi inclus în fiecare URL care este transmis clientului. Urmărirea sesiunii presupune faptul că aplicaţia ar trebui să rescrie URL-ul (folosind metoda encodeURL(String) pe obiectul răspuns) de fiecare dată când servlet-ul transmite un răspuns, astfel încât, în situaţia în care clientul dezactivează posibilitatea de a reţine cookie-uri, identificatorul să fie inclus în URL. În situaţia în care clientul acceptă cookie-uri, efectul metodei encodeURL(URL) este nul, lăsând URL-ul pe care îl primeşte ca parametru neschimbat.

Se doreşte implementarea unei interfeţe grafice cu utilizatorul (dezvoltată sub forma unei aplicaţii web, folosind serverul Apache Tomcat 8.x) pentru gestiunea informaţiilor reţinute într-o bază de date, aceasta urmând a fi utilizată de un sistem ERP destinat unei librării care comercializează doar cărţi.

Sistemul informatic va putea fi accesat de:

• un utilizator tip administrator, care va manipula – prin intermediul aplicaţiei – informaţiile din baza de date; acesta are la dispoziție operații de adăugare, editare și ștergere pentru oricare dintre tabele;
• un utilizator tip client, care va formula o comandă după ce şi-a specificat un anumit coş de cumpărături ca urmare a consultării catalogului de produse; pe baza comenzii va fi emisă o factură (invoice_header), caracterizată printr-un număr de identificare (identification_number), data la care a fost emisă (issue_date), stare (state) și identificatorul utilizatorului către care va fi transmisă (user_id); aceasta conține la rândul ei mai multe înregistrări, corespunzătoare cărților care au fost cumpărate (invoice_line), definite de factura corespunzătoare (invoice_header_id), identificatorul formatului de prezentare al cărții (book_presentation_id) și cantitatea (quantity).

Pentru fiecare funcționalitate există o pagină dedicată, gestionată de câte o clasă Java Servlet: pagina de autentificare (LoginServlet) de unde, în funcţie de rolul utilizatorului se trece la pagina de tip administrator (AdministratorServlet) respectiv pagina de tip client (ClientServlet).

0. Să se cloneze în directorul de pe discul local conținutul depozitului la distanță de la https://www.github.com/aipi2015/Laborator04. În urma acestei operații, directorul Laborator04 va trebui să conțină subdirectorul labtasks, fișierele README.md și LICENSE.

student@aipi2015:~$ git clone https://www.github.com/aipi2015/Laborator04.git

1. Să se ruleze, folosind MySQL Workbench (sau alt utilitar similar), scriptul Laborator04l.sql, localizat în directorul scripts. Acesta instalează baza de date bookstore.

2. Î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.

student@aipi2015:~/apache-tomcat-8.0.28$ cd bin
student@aipi2015:~/apache-tomcat-8.0.28/bin$ sudo chmod +x *.sh

3. Modificați în interfața Constants din pachetul ro.pub.cs.aipi.lab04.general informațiile necesare obținerii drepturilor de acces la baza de date (nume de utilizator, parola).

4. Să se configureze mediile integrate de dezvoltare astfel încât acestea să fie interfațate cu serverul web Apache Tomcat 8.x. Mai multe informații cu privire la modul în care poate fi realizată interfațarea dintre aceste componente pot fi găsite la serverul Apache Tomcat.

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

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 04-BookStore-JavaServlets (right-click), bifându-se opţiunea Always use this server when running this project.

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

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

Alternativ, se poate porni serverul Apache Tomcat și dezvolta aplicația web în contextul său și prin opțiunea Run (F6), care va lansa și browser-ul implicit în care va fi prezentată pagina principală a aplicației web.

5. Să se testeze aplicaţia prin accesarea adresei http://localhost:8080/04-BookStore-JavaServlets/.

Se poate consulta script-ul Laborator04l.sql există exemple de utilizatori care pot fi folosite pentru accesarea paginilor de administrator, respectiv de client.

• administrator: mary.smith / -
• client: linda.williams / -

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

7. Să se acceseze pagina de tip client. Să se implementeze funcționalitatea corespunzătoare filtrării în funcție de limbile în care sunt disponibile cărțile din librărie. Un utilizator poate adăuga o valoare din lista de limbi disponibile. Filtrarea se face în funcție de limbile selectate, pentru acele formate de prezentare a cărții care conțin cel puțin una dintre aceste valori. În situația în care nu s-a specificat nici o valoare, sunt incluse toate volumele comercializate. Un utilizator poate șterge una sau mai multe dintre limbile selectate anterior.

<spoiler|Indicații de Rezolvare> În clasa ClientGraphicUserInterface din pachetul ro.pub.cs.aipi.lab04.graphicuserinterface, se afișează lista cu limbile în funcție de care se realizează filtrarea, pentru fiecare dintre acestea atașându-se un buton pentru eliminarea valorii respective.

Se iterează pe lista cu filtre în funcție de limbi (obiectul languagesFilter), iar pentru fiecare element:

• se afișează șirul de caractere conținând limba;
• se afișează un element de tip <input>, având atributul type cu valoarea image și denumirea delete_language: _{language_name} (valori reținutr de constantele DELETE_BUTTON_NAME și LANGUAGE din interfața Constants). Resursa grafică se regăsește în directorul images, în subdirectorul user_interface, având denumirea delete.png (se recomandă să se forțeze dimensiunea acesteia la 16×16, prin specificarea atributelor width și height).

Elementele vor fi incluse ca linii în cadrul unui tabel (<tr><td>…</td></tr>).

În clasa ClientServlet din pachetul ro.pub.cs.aipi.lab04.servlets, se tratează acțiunile corespunzătoare evenimentelor de tip apăsare a butoanelor de tip insert, respectiv delete corespunzătoare filtrului în funcție de limba în care a fost selectată cartea.

• pentru parametrii având denumirea de tipul insert_language: (valori conținute de constantele INSERT_BUTTON_NAME, respectiv LANGUAGE din interfața Constants), se obține denumirea limbii (ca valoare atașată parametrului, prin invocarea metodei request.getParameter(parameter)), se verifică dacă aceasta nu este conținută în lista de limbi în funcție de care se face filtrarea și, în caz afirmativ, este adăugată la listă, marcându-se faptul că lista de filtre a fost modificată (parametrul filterChange de tip boolean);
• pentru parametrii având denumirea de tipul delete_language: _{language_name} (valori conținute de constantele DELETE_BUTTON_NAME, respectiv LANGUAGE din interfața Constants), se obține denumirea limbii (ca valoare atașată parametrului, prin invocarea metodei request.getParameter(parameter)), se verifică dacă aceasta este conținută în lista de limbi în funcție de care se face filtrarea și, în caz afirmativ, este ștearsă din listă, marcându-se faptul că lista de filtre a fost modificată (parametrul filterChange de tip boolean).

</spoiler>

8. În pachetul ro.pub.cs.aipi.lab04.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 deja existent să se poate actualiza cantitatea, astfel: dacă un produs există deja în coşul de cumpărături, cantitatea respectivă va fi suprascrisă, iar dacă aceasta este 0, produsul va fi şters din coşul de cumpărături.

<spoiler|Indicații de Rezolvare> În cazul în care se apasă un buton atașat unui câmp text pentru precizarea unei cantități pentru un anumit format de prezentare a unei cărți, este necesar să se realizeze următoarele operații:

• se identifică identificatorul formatului de prezentare a cărții și cantitatea corespunzătoare:

a) butonul are denumirea insert_shoppingcart_book_presentation_id unde book_presentation_id reprezintă identificatorul formatului de prezentare a cărții (de exemplu, insert_shoppingcart_1 pentru formatul de identificare a cărții cu identificatorul 1); prin parsarea denumirii acestui parametru se obține identificatorul formatului de prezentare a cărții:

if (parameter.startsWith(Constants.INSERT_BUTTON_NAME.toLowerCase() + "_" + Utilities.removeSpaces(Constants.SHOPPING_CART.toLowerCase()) + "_") && parameter.endsWith(".x")) {
  String bookPresentationId = parameter.substring(parameter.lastIndexOf("_") + 1, parameter.indexOf(".x"));
}

b) câmpul text ce conține cantitatea corespunzătoare are denumirea copies_shoppingcart_book_presentation_id unde book_presentation_id reprezintă identificatorul formatului de prezentare a cărții (de exemplu, copies_shoppingcart_1 pentru formatul de identificare a cărții cu identificatorul 1); valoarea corespunzătoare acestui parametru reprezintă cantitatea solicitată:

if (parameter.startsWith(Constants.INSERT_BUTTON_NAME.toLowerCase() + "_" + Utilities.removeSpaces(Constants.SHOPPING_CART.toLowerCase()) + "_") && parameter.endsWith(".x")) {
  String quantity = request.getParameter(Constants.COPIES.toLowerCase() + "_" + Utilities.removeSpaces(Constants.SHOPPING_CART.toLowerCase()) + "_" + bookPresentationId);
}

• se iterează asupra conținutului coșului de cumpărături (obiectul shoppingCart, transmis prin intermediul sesiunii, este de tipul List<Record> unde ca atribut se reţine identificatorul formatului de prezentare a cărţii, iar ca valoare cantitatea):
  • dacă se identifică un element având același identificator al formatului de prezentare a cărții:
    • în situația în care cantitatea este nenulă, aceasta este modificată;
    • în situația în care cantitatea este nulă, aceasta este ștearsă;
  • dacă nu se identifică un element având același identificator al formatului de prezentare a cărții, acesta este adăugată.

</spoiler>

9. În pachetul ro.pub.cs.aipi.lab04.graphicuserinterface, în clasa ClientGraphicUserInterface, să se completeze metoda displayClientGraphicUserInterface() astfel încât să se vizualizeze coţinutul coşului de cumpărături. Se va afişa numărul de exemplare comandate, titlul cărţii, formatul de prezentare și limba, precum şi suma pentru fiecare produs în parte, respectiv preţul total pentru întregul coş de cumpărături.

<spoiler|Indicații de Rezolvare> Se iterează asupra conținutului coșului de cumpărături (obiectul shoppingCart), determinându-se, pentru fiecare element, identificatorul formatului de prezentare (atributul) și cantitatea (valoarea).

Prețul unitar pentru un format de prezentare poate fi obținut apelând metoda getPrice() din clasa BookPresentationManager, ce primește ca argument identificatorul formatului de prezentare respectiv.

Informațiile cu privire la un format de prezentare (titlul, formatul de prezentare și limba) pot fi obținute apelând metoda getInformation() din clasa BookPresentationManager, ce primește ca argument identificatorul formatului de prezentare respectiv. Acesta întoarce o listă de obiecte de tip șir de caractere.

Este necesar să se calculeze și prețul total al coșului de cumpărături.

Prezentarea se va face în cadrul unui tabel (element de tip <table>), datele corespunzătoare unui obiect din coșul de cumpărături fiind incluse pe o linie a acestuia (<tr><td>…</td></tr>). </spoiler>

10. În pachetul ro.pub.cs.aipi.lab04.graphicuserinterface, în clasa ClientGraphicUserInterface să se completeze metoda displayClientGraphicUserInterface() astfel încât să se adauge două butoane prin care se poate anula, respectiv finaliza o comandă, în condițiile în care există produse în coșul de cumpărături.

<spoiler|Indicații de Rezolvare> Resursele grafice pentru butoane se regăsesc în directorul images, în subdirectorul user_interface, având denumirile:

• remove_from_shopping_cart.png;
• shopping_cart_accept.png;

Butoanele vor fi incluse în cadrul unui element de tip <input>, având atributul type cu valoarea image și denumirile cancelcommand, respectiv completecommand (valori conținute de constantele CANCEL_COMMAND și COMPLETE_COMMAND din interfața Constants, pentru care se elimină spațiile și se folosesc numai minuscule). Locațiile la care se găsesc resursele ce vor fi afișate vor fi precizate în cadrul atributului src. </spoiler>

11. În pachetul ro.pub.cs.aipi.lab04.servlets, în clasa ClientServlet, metoda doPost(), să se implementeze operaţiile de anulare, respectiv finalizare a unei comenzi.

<spoiler|Indicații de Rezolvare> În cazul anulării unei comenzi, se şterge conţinutul obiectului shoppingCart.

În cazul finalizării unei comenzi, trebuie realizate următoarele operaţii:

• se adaugă o înregistrare în tabela invoice_header; se va folosi metoda create() din cadrul clasei InvoiceHeaderManager pentru care trebuie precizate valorile ce vor fi adăugate, aceasta furnizând identificatorul înregistrării din tabelă:
  • numărul de identificare (câmpul identification_number) va fi generat aleator folosind metoda Utilities.generateIdentificationNumber(), care primește ca parametri numărul de caractere de tip literă (3), respectiv cifră (6);
  • data de emitere (câmpul issue_date) - ziua curentă - va fi obținută folosind metoda now() din clasa LocalDate;
  • starea (câmpul state) are valoarea issued reținut de constanta STATE_ISSUED din interfața Constants;
  • identificatorul utilizatorului (câmpul user_id) va fi determinat pe baza denumirii (stocate în obiectul display) - concatenarea dintre prenumele şi numele reţinute în tabela user - prin apelul metodei getIdentifier() din clasa UserManager;
• se iterează asupra conținutului coșului de cumpărături (obiectul shoppingCart):
  • se obține identificatorul formatului de prezentare a cărții (atributul), cantitatea (valoarea) și stocul corespunzător, așa cum este reținut în tabela book_presentation (prin apelul metodei getStockpile()) din clasa BookPresentationManager);
  • se compară numărul de exemplare din coşul de cumpărături cu stocul existent şi în situația în care comanda poate fi satisfăcută, se actualizează stocul (se apelează metoda update() din clasa BookPresentationManager care primește ca parametri atât atributul cât și valoarea care trebuie să fie modificate);
  • se adaugă o înregistrare în tabela invoice_line; se va folosi metoda create() din cadrul clasei InvoiceLineManager pentru care trebuie precizate valorile ce vor fi adăugate:
    • identificatorul facturii (câmpul invoice_header_id), determinat anterior;
    • identificatorul formatului de prezentare a cărții (câmpul book_presentation_id);
    • cantitatea (câmpul quantity);
• se goleşte coşul de cumpărături.

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

</spoiler>

12. 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.

<spoiler|Indicații de Rezolvare> În clasa ClientGraphicUserInterface, se afișează un element de tip <input>, având atributul type cu valoarea image și denumirea signout (valoare reținută de constanta SIGNOUT din interfața Constants). Resursa grafică se regăsește în directorul images, în subdirectorul user_interface, având denumirea signout.png.

În clasa ClientServlet, în cazul în care a fost apăsat butonul pentru operația de deautentificare:

• se obține lista cu toți parametrii (metoda getParameterNames() din clasa ServletRequest), aceștia fiind eliminați, prin invocarea metodei removeAttribute();
• se elimină elementele conținute de listele shoppingCart, formatsFilter, languagesFilter, categoriesFilter;
• valorile conținute de obiectele previousRecordsPerPage, currentRecordsPerPage, currentPage vor fi cele implicite;
• se elimină conținutul obiectului books;
• se transferă contextul către servletul care gestionează operația de autentificare (LoginServlet):

  RequestDispatcher dispatcher = getServletContext().getRequestDispatcher("/" + Constants.LOGIN_SERVLET_PAGE_CONTEXT);
  if (dispatcher != null) {
    dispatcher.forward(request, response);
  }

• se invalidează sesiunea prin invocarea metodei invalidate() pe obiectul de tip HttpSession, - după această operație nu mai este permis să se utilizeze pagina Internet curentă;

  session.invalidate();

</spoiler>

Eric Jendrock, Ricardo Cervera- Navarro, Ian Evans, Kim Haase, William Markito - The Java EE 7 Tutorial - capitolele 6 (subcapitolul 6.1), 17
Apache Tomcat
Apache Tomcat - More about the Cat
Servlets Tutorial
Servlets Tutorial
Java Server-Side Programming
Building Web Apps in Java: Beginning & Intermediate Servlet & JSP Tutorials
Advanced Servlet and JSP Tutorials

Proiect Eclipse
Proiect NetBeans