Informatic a aplicat a [607470]

Universitatea Transilvania din Bra sov
Facultatea de Matematic a  si Informatic a
Informatic a aplicat a
Lucrare de Licent  a
Doc-shelf
Bibliotec a de stocare  si indexare a
documentelor digitale
Autor: Rodocea Adina M ad alina
Coordonator: Conf. Dr. DUMITRESCU Silviu
Bra sov, 2016

Cont inut
Introducere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1 Tehnologii utilizate 6
1.1 Tehnologii pe partea de Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.1 Tehnologii Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.1.1 Apache Solr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.1.2 Apache Tika . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.1.3 SolrJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1.2 Spring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.2.1 Spring Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1.2.2 Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.1.2.3 Spring Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.1.3 Java Server Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2 Tehnologii pe partea de Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.2.1 PrimeFaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.2.2 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.3 Alte tehnologii utilizate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.3.1 Gradle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.3.2 Ghostscript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.3.3 Ghost4j . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1

2 Implementarea solut iei 33
2.1 Prezentare general a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2 Congurat ia proiectului . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.1 Congurat ia Gradle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.2 Congurat ia Solr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2.3 Congurat ia Tika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3 Descrierea codului surs a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4 Descrierea altor resurse folosite . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3 Funct ionalitatea aplicat iei 71
3.1 C autarea documentelor ca utilizator neautenticat . . . . . . . . . . . . . . . . . 72
3.2 ^Inregistrare  si autenticare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.3 ^Inc arcarea, accesarea  si manipularea  sierelor . . . . . . . . . . . . . . . . . . . 75
3.4 C autarea documentelor ca utilizator autenticat . . . . . . . . . . . . . . . . . . 79
4 Direct ii ulterioare de dezvoltare 81
5 Concluzii 84
6 Bibliograe 86
2

Introducere
Accesul facil la informat ie a fost considerat mult timp o utopie de c atre oamenii de  stiint  a.
Odat a cu ^ mbun at at irea infrastructurii IT  si a comunicat iilor, sistemul ret elelor informatice
necesar pentru a sprijini un astfel de acces la date a devenit fezabil.
Ast azi, volumul mare de date ^ n format electronic, disponibil online, nu mai reprezint a
ceva inedit. Num arul populat iei care nu doar consum a, ci  si genereaz a cont inut digital, se a
 a
^ ntr-o expansiune continu a. Acest fapt se datoreaz a ^ n mare parte activit at ilor de rutin a care
tind s a se transpun a din ce ^ n ce mai mult spre mediul virtual. Astfel, omul de r^ and, lipsit de
o bun a cunoa stere a domeniului informatic, a ajuns, poate de multe ori ^ ntr-un mod nu pe
deplin con stient, s a manipuleze date. Accesarea sau distribuirea de resurse electronice a
devenit un lucru comun, natural, migrarea informat iei de pe h^ artie pe calculator, al aturi de
aparit ia primelor biblioteci digitale, av^ and loc ^ n jurul anilor '60. Totu si, aceste sisteme de
biblioteci electronice au evoluat exponent ial de la aparit ia lor timpurie. S-a ajuns ca ele s a
reprezinte sisteme complexe de ret ea, capabile s a comunice  si s a colaboreze ^ ntre diferite
comunit at i distribuite la nivel mondial, care se ocup a cu 'obiecte digitale', acestea cuprinz^ and
nu doar echivalentul digital al documentelor imprimate, ci  si imagini, lme, ^ nregistr ari audio
sau orice alt tip de obiecte multimedia.
Nevoia de a p astra ^ n mod sigur o colect ie de date ^ ntr-un singur loc a dus la na sterea
acestei distribut ii digitale ^ n cadrul bibliotecilor virtuale, a c aror scop principal este mai
3

degrab a acela de a permite c autarea c^ at mai ecient a a materialelor electronice dec^ at crearea
de arhive. ^In acest sens, se pune problema tehnologiei folosite pentru reg asirea informat iei
dorite.
Lucrarea de fat  a ^  si propune s a acopere c^ ateva dintre facilit at ile puse la dispozit ie de astfel
de sisteme, cum ar  Google Books sau Project Gutenberg , printr-o abordare ce denot a
curiozitate ^ n ceea ce prive ste tehnologiile implicate ^ n dezvoltare. Se va pune accentul pe
indexarea  si stocarea documentelor electronice printr-o procedur a ce include extragerea
metadatelor acestora, reg asirea cu c^ at mai mare acuratet e a resurselor indexate pe baza
input-ului generat de utilizator, dar  si oferirea unui mediu
exibil pentru simularea unor
condit ii reale ^ n care utilizatorul s a aib a acces la resursa c autat a. ^In cadrul aplicat iilor de
acest tip, metodele de c autare joac a un rol central.
Pentru ilustrarea celor ment ionate relativ la capabilit at ile aplicat iei curente legate de
c autarea ^ n cadrul documentelor salvate, se vor folosi  si descrie facilit at ile oferite de platforma
Apache Solr  si se va prezenta implementarea unei biblioteci virtuale ^ n care c autarea se va
realiza cu ajutorul acestui produs software. Apache Solr este o platform a de c autare open
source, parte integrant a a proiectului Apache Lucene , ce funct ioneaz a ca o baz a de date care
implementeaz a o serie de algoritmi pentru full-text search .
Scopul lucr arii este, deci, unul ce acoper a at^ at partea teoretic a, dar  si pe cea practic a a
cre arii unei astfel de aplicat ii, tip de aplicat ie devenit at^ at de popular ^ n r^ andul consumatorilor
 si a generatorilor de resurse digitale ^ n ultimul timp, datorit a nevoii de dinamism a oamenilor
 si a avantajelor cu care se prezint a ^ n fat a utilizatorilor:
Nicio limit a zic a – utilizatorul unei biblioteci virtuale nu este nevoit s a fac a vreun efort
zic, iar aceea si resurs a poate  accesat a de mai mult i utilizatori ^ n acela si timp, at^ ata
timp c^ at o conexiune la Internet este disponibil a.
4

Disponibilitatea permanent a – oamenii pot avea acces 24/7 la informat ii.
Reg asirea informat iei – utilizatorul poate folosi orice termen de c autare (cuv^ ant, fraz a,
titlu, nume, subiect) pentru a c auta prin ^ ntreaga colect ie.
Conservare – distribut ia digital a nu reprezint a o solut ie pe termen lung pentru conservarea
colect iilor zice, ^ ns a ofer a cu succes copii pentru materialele care, altfel, s-ar degrada din
cauza acces arii repetate.
Spat iu – ^ ntruc^ at bibliotecile tradit ionale sunt limitate de spat iul de stocare, bibliotecile
digitale au potent ialul de a stoca mult mai multe informat ii, c aci informat ia digital a are
nevoie de foarte put in spat iu pentru depozitare, iar tehnologia de stocare a devenit tot
mai accesibil a.
Valoare ad augat a – anumite caracteristici ale obiectelor, cum ar  calitatea imaginilor, ar
putea  ^ mbun at at ite, digitizarea put^ and spori lizibilitatea  si elimina defectele vizibile,
cum ar  petele ori decolorarea.
^In urma analizei celor expuse  si ind un utilizator constant ^ n cadrul diverselor biblioteci
digitale disponibile ^ n mediul online, am considerat c a implementarea unei solut ii proprii cu
ajutorul unor tehnologii neutilizate p^ an a ^ n momentul ^ nceperii dezvolt arii aplicat iei reprezint a
o oportunitate interesant a  si provocatoare de l argire a sferei cuno stint elor.
5

Capitolul 1
Tehnologii utilizate
1.1 Tehnologii pe partea de Server
^In ceea ce urmeaz a se va face o trecere ^ n revist a a tehnologiilor folosite pe partea de server.
1.1.1 Tehnologii Apache
1.1.1.1 Apache Solr
Ce este Apache Solr?
Apache Solr este o platform a open source de c autare, scris a ^ n Java, ind un subproiect al
Apache Lucene . Caracteristicile sale majore includ:
C autarea avansat a full-text -Solr pune la dispozit ie capabilit at i puternice de reg asire nu
doar a unui cuv^ ant specicat, c autarea put^ andu-se realiza  si ^ n funct ie de anumite fraze,
caractere de tip wildcard sau a diverselor grup ari de cuvinte;
Optimizarea pentru un trac ridicat – platforma e folosit a pe scar a larg a ^ n ^ ntreaga lume;
Folosirea unor tool-uri standardizate precum XML, JSON sau HTTP, ceea ce face ca
framework-ul s a poat a  u sor de utilizat ^ n cadrul celor mai populare limbaje de
6

programare;
Existent a unei interfet e de administrare – instant ele de Solr sunt, astfel, u sor de controlat;
Indexarea ^ n timp real;
Integrarea cu baza de date;
Manipularea documentelor de tip PDF, Word, etc;
Scalabilitatea, tolerant a la defecte,
exibilitatea, extensibilitatea;
C autarea geospat ial a – Solr ofer a suport pentru c autarea ^ n funct ie de locat ie;
Analiza avansat a  si congurabil a a datelor textuale – e oferit suport pentru cele mai
vorbite limbi de pe glob (englez a, chinez a, japonez a, german a, francez a  si multe altele),
ceea ce^ nseamn a c a se poate identica limba^ n care documentele sunt scrise, iar indexarea
 si interogarea devin mult mai
exibile.
Solr ^ nlesne ste, a sadar, munca programatorilor ^ n ceea ce prive ste dezvoltarea de aplicat ii
sosticate  si performante de c autare. Acest server se bazeaz a pe Lucene , o alt a bibliotec a java
defull-text search ce ast azi cunoa ste un grad foarte larg de r asp^ andire, ind clasat a printre
primele 15 proiecte open source la momentul curent.
De ce Apache Solr?
Exist a o tendint  a a utilizatorilor ne^ ndeajuns informat i de a compara Solr cu o colect ie de
date. ^In schimb, acesta ar trebui privit drept un index, scopul lui neind acela de a ^ ndeplini
sarcini specice SQL-ului, spre exemplu. Se pune, deci, problema folosirii Solr-ului ^ n
defavoarea bazelor de date relat ionale. Ceea ce trebuie cunoscut aprioric este faptul c a bazele
de date tradit ionale  si acest server de c autare avansat a au puncte slabe, respectiv puncte forte
complementare, iar decizia de a alege ^ ntre cele dou a ^ n cazul unei aplicat ii trebuie bine
7

c^ ant arit a.
Solr vs. Bazele de date relat ionale
Caracteristici Solr Baz a de date relat ional a
C autare text Rapid a, sosticat a Lent a, minimal a
Complexitatea
implement ariiMedie Medie
Flexibilitatea schemei E necesar un rebuild de
obiceiSchimb arile sunt vizibile
imediat
Viteza de indexare Lent a Mai rapid a  si ajustabil a
Viteza de interogare Rapid a Dependent a de use case
Modicarea part ial a a
^ nregistr arilorNu Da
Cuno stint e tehnice necesare Java (minimal), pornirea
serverului web, ITSQL, IT
.
Din ceea ce reiese din tabelul de mai sus, putem enunt a faptul c a Solr este cu adev arat util
atunci c^ and se pune problema performant ei, a caracteristicilor de c autare avansat a pe care
dorim s a le abord am sau ^ n cazul ^ n care ne intereseaz a s a utiliz am unelte puse la dispozit ie de
acest framework precum cele care ne ofer a posibilitatea de a calcula un 'scor' al rezultatelor,
scor ce se calculeaz a ^ n funct ie de un anumit num ar de parametri, at^ at la indexare, c^ at  si ^ n
momentul c aut arii. De exemplu, ne putem imagina cazul unui magazin online care ofer a at^ at
materiale ^ n mod gratuit, dar  si unele ce necesit a un anumit cost. ^In acest caz, e de dorit pentru
det in atorul site-ului ca materialele care nu sunt gratuite s a e prioritare, acestea tinz^ and s a
apar a primele printre rezultatele c aut arilor. Pentru scenariul anterior, Solr poate facilita a sadar
c autarea, acest lucru realiz^ andu-se urm^ and urm atorii pa si:
1. Denirea unei scheme – schema comunic a Solr-ului informat ii legate de cont inutul
8

documentelor ce vor  indexate. Relu^ and exemplul magazinului online, schema ar avea
rolul de a deni c^ ampuri pentru denumirea produselor, descriere, pret , produc ator,
 s.a.m.d. Aceast a schem a este
exibil a, permit ^ and s a adapt am comportamentul Solr-ului
la aplicat ia ce urmeaz a a  dezvoltat a
2. Lansarea serverului Solr
3. Indexarea documentelor pentru care utilizatorii vor aplica ltre de search
4. Ad augarea de funct ionalit at i de c autare ^ n cadrul aplicat iei
Se pleac a, deci, de la o premis a simpl a. Solr-ul prime ste un volum mare de informat ie,
utilizatorul poate mai departe interoga serverul pentru a g asi informat ia dorit a, schema
despre care aminteam mai ^ nainte ind locul unde Solr-ului i se comunic a cum ar trebui s a
construiasc a indec si pe baza documentelor indexate. Unitatea principal a de masur a a
informat iei ^ n lumea Solr este documentul , un set de date compus din c^ ampuri, ce reprezint a
informat ii mai specice  si care pot  reprezentate de diferite tipuri de date. C^ and un
document este ad augat, Solr preia informat iile din c^ ampurile documentului  si le adaug a la un
index. ^In momentul ^ n care se efectueaz a o interogare, Solr poate consulta rapid indexul  si
poate returna documentele care se potrivesc cu interogarea. Denirea  si detaliile legate de
tipul c^ ampurilor se realizeaz a ^ n schema.xml ,  sierul de congurare al Solr care se ocup a cu
denirea schemei documentelor indexate.
Urm atorul exemplu dene ste un c^ amp numit price , de tip
oat, cu o valoare implicit a de
0.0, cu o proprietate indexed true, ceea ce ^ nseamn a c a aceasta poate  folosit a ^ n query-uri
pentru a returna documente care se potrivesc cu ea,  si cu o alt a proprietate stored setat a pe
true, ceea ce ^ nseamn a c a valoarea c^ ampului poate  reg asit a dup a aplicarea interog arilor.
Lista 1.1: Denirea unui c^ amp ^ n schema.xml
1<f i e l d name=" p r i c e " type=" f l o a t " d e f a u l t=" 0.0 " indexed=" true " stored=" true "/ >
9

Unul dintre c^ ampuri este de obicei desemnat drept un c^ amp ID unic (analog cu o cheie
primar a dintr-o baz a de date), de si utilizarea unui c^ amp de identicare unic nu e strict
necesar ^ n Solr.
Prin ad augarea de cont inut la un index, se garanteaz a proprietatea acestuia de a putea
c autat. Un index de Solr poate accepta date din diferite surse, printre care  siere XML, CSV,
date extrase din tabele ^ n baze de date, respectiv formate de  siere comune, precum PDF sau
Microsoft Word. Cele mai comune moduri de a ^ nc arca date ^ ntr-un index Solr sunt utilizarea
framework-ului Solr Cell , transmiterea de cereri HTTP c atre server-ul Solr  si scrierea unei
aplicat ii Java pentru ad augarea de date prin intermediul API-ului Java Client Solr .
Un alt  sier de congurare important este solrcong.xml , care cont ine opt iuni de
congurare  si a sa numitele "request handlers", responsabile cu r aspunsul la cereri. Pe l^ ang a
acestea, se pot deni anumite "search handlers", care se ocup a cu returnarea unei liste de
rezultate personalizate.
Toate aceste opt iuni avansate de c autare pe care le-am specicat, al aturi de multe altele  si
de viteza de care d a dovad a Solr-ul, contribuie la construirea unei aplicat ii ^ n care c autarea e
^ n plan primar. Solr folose ste clase din biblioteca Apache Lucene pentru a construi indexul
denumit inverted index , o modalitate de a crea un index de c autare care listeaz a ecare
cuv^ ant  si documentele care cont in acest cuv^ ant. De aici reiese  si viteza mare de reg asire
oferit a de acest server, care nu aplic a o c autare alternativ a pas cu pas, care ar consta din
crearea unei liste de documente asociate cu ecare cuv^ ant folosit ^ n ecare document. Din
moment ce utilizatorii aplic a operat ii de c autare folosind termeni pe care s-ar a stepta s a-i
g aseasc a ^ n documente, identicarea termenului ^ nainte de cea a ^ ntregului document salveaz a
resurse de timp  si procesare.
10

1.1.1.2 Apache Tika
Ce este Apache Tika?
Apache Tika este o bibliotec a scris a ^ n Java, folosit a at^ at pentru detectarea tipului a peste
o mie de  siere diferite, c^ at si pentru extragerea de informat ii pe baza acestor  siere. Cu
ajutorul ei se poate dezvolta un detector universal  si o metod a sigur a de extragere a
cont inutului variatelor  siere, at^ at cont inut text, c^ at  si metadate. Dintre  sierele suportate
amintim foile de calcul,  sierele text,  sierele PDF, imaginile  si ^ ntr-o oarecare m asur a
documentele multimedia. Tika ofer a un singur API generic pentru parsarea diferitelor
formate de  sier, acesta folosind numeroase biblioteci de parsare pentru ecare tip de
document ^ n parte, toate aceste biblioteci ind ^ ncapsulate sub o singur a interfat  a, denumit a
interfat a Parser .Tika poate  u sor integrat a ^ ntr-o aplicat ie, acest framework oferind un
CLI (command line interface), dar  si o interfat  a grac a pentru sporirea interactivit at ii cu
utilizatorul. Arhitectura sa e bazat a pe patru module:
1.Mecanismul de detect ie a limbii
^In momentul pas arii unui document c atre Tika, framework-ul detecteaz a limba ^ n care
acesta a fost scris. Clasa care joac a un rol central ^ n funct ionarea corect a a acestui
mecanism este LanguageIdentier , reg asit a ^ n pachetul org.apache.tika.language ,
intern ind utilizat i algoritmi de tip N-gram pentru detectarea limbii.
2.Mecanismul de detectare a tipurilor MIME
Este vorba despre abilitatea framework-ului de a detecta  si extrage cont inut din toate
tipurile de date incluse ^ n standardele MIME. ^In acest sens, pe plan intern Tika utilizeaz a
tehnici precum "magic bytes", "content-type hints" sau codicarea caracterelor.
3.Interfat a Parser
Aceast a interfat  a este punctul cheie pentru parsarea documentelor ^ n cadrul Tika, ea
ocup^ andu-se cu extragerea textului  si a metadatelor din documente.
11

4.Clasa Facade din Tika
Utilizarea ei reprezint a cea mai simpl a  si direct a modalitate de a chema Tika prin
intermediul Java, ind o clas a ce utilizeaz a  sablonul de proiectare Facade. Cont ine
metode prin care se pot explora toate funct ionalit at ile acestui framework.
De ce Apache Tika?
Conform statisticilor, num arul tipurilor de date se a
 a ^ ntr-o continu a cre stere. Drept
urmare, aplicat ii precum motoarele de c autare sau sistemele de management a cont inuturilor
au o nevoie stringent a de tehnologie avansat a, care s a le ofere suportul unei extrageri facile a
informat iilor din diversele tipuri de documente. Apache Tika exact aici intervine, oferind un
API generic pentru detect ia  si extragerea de date din tipuri diferite de  siere. Astfel,
framework-ul este folosit ^ ndeosebi ^ n dezvoltarea motoarelor de c autare pentru indexarea
cont inutului documentelor digitale, ^ n domeniul inteligent ei articiale sau a managementului
produselor digitale, caracteristicile sale recomand^ andu-l negre sit: consumul redus de resurse
de memorie, procesarea rapid a  si
exibilitatea ^ n recunoa sterea oric arui tip de metadat a
folosit.
Apache Tika  si Solr
Clasa ExtractingRequestHandler , specic a Solr-ului, folose ste Tika pentru a oferi
posibilitatea utilizatorilor de a ^ nc arca  siere binare, de unde Solr-ul s a extrag a metadate,
urm^ and ca mai apoi documentele s a e indexate. Tika va ^ ncerca ^ n mod automat s a
determine tipul documentului  si s a extrag a cont inutul, ^ ns a se poate specica un tip MIME ^ n
mod explicit. ExtractingRequestHandler e
exibil ^ n realizarea map arii cont inutului  si a
diferitelor c^ ampuri, acest modul necesit^ and congurarea ^ n cadrul  sierului solrcong.xml .
12

Lista 1.2: Exemplu congurare ExtractingRequestHandler
1<requestHandler name="/update/ e x t r a c t " >
2<l s t name=" d e f a u l t s " >
3<s t r name=" ext . map . Last Modified " >l a s t m o d i f i e d </ s t r>
4
5<bool name=" ext . ignore . und . f l " >true</ bool >
6</ l s t>
7</ requestHandler >
Odat a congurat acest handler, e de ajuns ca Solr-ul s a e pornit, iar un document s a e
trimis spre indexare, acest lucru put^ andu-se realiza din linia de comand a sau prin intermediul
oric arui tool de HTTP POST, f ar a a se trece ^ ns a cu vederea peste necesitatea de a comite
mesajul c atre Solr. Pentru a verica faptul c a se pot opera c aut ari ^ n cadrul documentului
indexat se va deschide interfat a de administrare a Solr-ului. Apache Solr , ^ n combinat ie cu
ExtractingRequestHandler se dovede ste a  un tandem puternic  si u sor de setat, cu un
potent ial imens. Avantajul principal de a avea componenta de parsare  si extragere pe partea
de server e faptul c a clientul nu trebuie s a ^ nt eleag a toate aspectele care se a
 a ^ n spatele
acestei tehnologii. Folosind Tika, procesul de ad augare de interpretori pentru noi tipuri de
documente este u sor, c aci nu aduce dezvoltatorul ^ n situat ia de a modica sau de a ad auga
nou cod. Totu si, exist a  si cazuri ^ n care are sens s a se utilizeze Tika pe partea de client. Un
astfel de use case ar  acela ^ n care se dore ste indexarea, iar c autarea va  realizat a doar ^ n
funct ie de metadate. Dac a documentele peste care se opereaz a c autarea sunt de mari
dimensiuni, atunci parsarea lor pe partea de client  si trimiterea c atre Solr doar a metadatelor
e o solut ie mult mai put in costisitoare.
13

1.1.1.3 SolrJ
Ce este SolrJ?
Orice aplicat ie de c autare are nevoie s a interact ioneze cu Solr prin emiterea de indec si  si
cereri de c autare. Chiar dac a Solr expune aceste servicii  si prin intermediul unor cereri
HTTP, acest nivel de lucru nu este la ^ ndem^ ana dezvoltatorilor de ecare dat a. Client
API-urile sunt biblioteci de tip Facade care ascund detaliile comunic arii client-server. Ele
permit interact iunea cu Solr prin intermediul unor structuri POJO (Plain Old Java Object).
Solr ofer a biblioteca SolrJ , un client Java pentru accesarea server-ului Solr din interiorul
aplicat iei noastre. Acesta vine la pachet cu metode de creare a documentelor, de indexare a
acestora, de formare a query-urilor, metode capabile s a efectueze c autare  si s a itereze peste
rezultatele g asite. Fiind single-threaded , programatorii utilizeaz a SolrJ pentru dezvoltarea de
aplicat ii de import personalizate, capabile s a proceseze volume mari de date. SolrJ
^ nlocuie ste, a sadar, stratul transport HTTP  si ofer a o interfat  a simpl a de comunicare cu
Solr-ul. Un astfel de API are nevoie de obicei de un proxy sau un facade, reprezent^ and
resursa remote care ascunde interact iunea client-server, iar ^ n cazul SolrJ , acest rol este jucat
de clasele care implementeaz a clasa abstract a SolrServer . Dintre acestea, cea mai des
utilizat a r am^ ane HttpSolrServer , ind mai potrivit a pentru emiterea interog arilor.
Dup a cum am ment ionat  si ^ n sect iunea anterioar a, documentul este conceptul central al
Solr-ului. SolrJ separ a documentele de intrare de cele de ie sire cu ajutorul claselor
SolrInputDocument , respectiv SolrDocument . Chiar dac a ambele folosesc acelea si
comportamente de transfer de date, ecare are caracteristicile sale specice, asociate cu
interact iunea dintre client  si server. SolrInputDocument e un obiect ce suport a ad augarea,
modicarea sau  stergerea de c^ ampuri, ^ n timp ce prin intermediul SolrDocument putem
accesa valorile sau numele c^ ampurilor. Astfel, SolrInputDocument se va folosi ^ n momentul
ad aug arii de date ^ n Solr, iar instant e ale SolrDocument vor  create dup a executarea
14

query-urilor, cu ajutorul QueryResponse . Odat a ce e creat a o referint  a valid a la
SolrClient , ad augarea datelor ^ n Solr  si  stergerea acestora devine o operat iune foarte u soar a.
Pentru realizarea c aut arii, intr a ^ n discut ie alte dou a clase, SolrQuery , respectiv
QueryResponse . Prima desemneaz a obiectul ce reprezint a query-ul ce poate  trimis c atre
Solr, iar a doua e r aspunsul la interogare.
Framework-ul SolrJ poate  folosit ^ n mod facil, ind nevoie de introducerea unei
dependint e, iar dup a cum am descris mai sus, aduce un plus c^ and vine vorba de conectarea la
Solr, indexarea datelor  si returnarea rezultatelor.
1.1.2 Spring Framework
Dezvoltat^ n 2003 de c atre Rod Johnson, Spring este^ n prezent cea mai popular a platform a open
source care ofer a suport complet ^ n infrastructura simpl a a aplicat iilor Java. Caracteristicile de
baz a ale platformei pot  folosite ^ n dezvoltarea oric arei aplicat ii Java, unul din obiectivele sale
ind acela de a face mai u soar a dezvoltarea J2EE  si de a promova bune practici de programare
prin activarea unui model de programare bazat pe POJO. ^In ceea ce urmeaz a, se va prezenta
o list a cu beneciile utiliz arii acestui framework:
Spring permite programatorilor s a dezolte aplicat ii Enterprise folosind POJO, obiecte
standard ale limbajului Java, unul din benecii ind acela c a nu este nevoie ^ n acest caz
de un produs care s a sust in a EJB-ul, cum ar  un server de aplicat ii, put^ and  folosite
doar servlet containers precum Tomcat, ce ofer a un plus de mobilitate.
Framework-ul este organizat ^ ntr-o manier a modular a. Chiar dac a num arul de pachete
 si clase este unul substant ial, dezvoltatorii pot selecta doar modulele care cuprind
funct ionalit at i dorite, ignor^ andu-le pe restul.
15

Platforma utilizeaz a beneciile oferite de tehnologii existente precum framework-urile
ORM sau de logging, JEE, Quartz,  s.a.m.d.
Testarea unei aplicat ii scris a cu ajutorul Spring devine simpl a, ^ ntruc^ at platforma cont ine
facilit at i menite s a simplice procesul. Mai mult, folosind obiecte Java ^ n containere de
tip Bean, devine u soar a folosirea inject iei de dependint e pentru a injecta date de test.
Modulul Spring specializat ^ n crearea aplicat iilor web, numit Spring MVC , ofer a o
alternativ a competitiv a  si ecient a fat  a de alte framework-uri din acest domeniu,
precum Struts.
Spring ofer a o modalitate ecient a pentru a translata erorile tehnice (generate de JDBC,
Hibernate sau JDO, spre exemplu) ^ n except ii consistente, u sor de ^ nt eles.
Permite dezvoltarea  si implementarea aplicat iilor pe computere cu memorie  si resurse
CPU limitate.
Platforma ofer a aproximativ 20 de module care pot  folosite ^ n funct ie de cerint ele
aplicat iei ce urmeaz a a  dezvoltat a. Cele mai importante module se grupeaz a ^ n:
Core Container
Cuprinde modulele: Core (ofer a componentele fundamentale ale framework-ului, inclusiv
IoC (inversion of control)  si Dependency Injection), Beans (cont ine o implementare
sosticat a a  sablonului Factory, numit a BeanFactory ),Context (punctul central al
modulului este reprezentat de interfat a ApplicationContext ),Expression Language
(ofer a un limbaj puternic pentru interogare  si manipulare a obiectelor la runtime).
Data Access/ Integration
Cuprinde modulele: JDBC ,ORM (satisface integrarea cu diverse API-uri, precum JPA,
JDO, Hibernate), OXM ,JMS (cont ine funct ii pentru producerea de mesaje), Transaction .
16

Web
Cuprinde modulele: Web ,Web-MVC (cont ine implementarea model-view-controller
pentru aplicat ii web), Web-Socket ,Web-Portler .
1.1.2.1 Spring Core
Tehnologia cu care Spring este cel mai des asociat r am^ ane Dependency Injection , exemplu
concret al conceptului de Inversion of Control . Scrierea unei aplicat ii complexe ^ n Java
impune anumite standarde, iar clasele aplicat iei ar trebui s a e c^ at mai independente posibil
pentru sporirea posibilit at ii de a  refolosite  si pentru a putea  testate individual. Dependency
Injection vine cu posibilitatea de a crea o leg atura^ ntre aceste clase, care, ^ n acela si timp, r am^ an
independente. Acest concept se poate efectua ^ n cazul pas arii de parametri constructorilor sau
prin mecanismul de post-construction , prin intermediul setter -ilor.
Lista 1.3: Scenariu f ar a Inversion of Control
1public class Employeef
2 private Address address ;
3 public Employee ( )f
4 address = new Address ( ) ;
5g
6g
Pentru ilustrarea scenariului care folose ste principiul Spring deInversion of Control , vom
modica codul precedent:
17

Lista 1.4: Scenariu cu Inversion of Control prin pasarea unui parametru constructorului
1public class Employeef
2 private Address address ;
3 public Employee ( Address address ) f
4 this . address = address ;
5g
6g
Astfel, codul devine mai put in cuplat, mai u sor de testat  si de ^ ntret inut.
Obiectele specice aplicat iei pe care dorim s a o dezvolt am  si care sunt gestionate de c atre
container-ul Spring IoC se numesc beans . Un bean este un obiect care e instant iat, asamblat
 si gestionat de un container IoC, put^ and  creat cu ajutorul metadatelor de congurare pe care
dezvoltatorul le furnizeaz a container-ului. Containerul are nevoie de aceste metadate pentru
a  sti cum s a creeze un bean, care sunt dependint ele bean-ului  si pentru a a
a detalii despre
ciclul de viat  a al acestuia. Exist a trei metode de baz a prin intermediul c arora se pot furniza
metadate de congurare c atre Spring Container :
1.Fi sier de congurare XML
Lista 1.5: Crearea unui bean printr-un sier de congurare XML
1<beans >
2 <bean id=" helloWorld " c l a s s="com . example . HelloWorld " / >
3</ beans >
2.Congurare bazat a pe adnot ari
Exist a posibilitatea de a muta congurarea unui bean din  sierul XML chiar ^ n clasa
doritu a, prin utilizarea de adnot ari pe clasa, metoda sau c^ ampul relevant. Acest tip de
18

adnotare nu este unul implicit, iar pentru a-l putea folosi este nevoie ca ^ n interiorul
 sierului de congurare de tip XML s a specic am: <context:annotation-cong / >
Odat a ^ ndeplinit a congurat ia, codul poate  adnotat pentru a indica faptul c a Spring
trebuie s a injecteze ^ n mod automat valori ^ n cadrul propriet at ilor, a metodelor sau
constructorilor. Astfel de adnot ari sunt:
@Required – se aplic a pe metodele de set ale bean-urilor  si indic a faptul c a
proprietatea bean-ului trebuie s a e populat a la momentul congur arii, e printr-o
valoare explicit a ^ n cadrul unui bean denition , e prin mecanismul de autowiring
@Autowired – comunic a Spring -ului unde trebuie s a aib a loc o inject ie
@PostConstruct – nu e adnotare exclusiv a a Spring -ului, dene ste o metod a ce va
 apelat a dup a ce bean-ul este complet init ializat, cu alte cuvinte va  apelat a dup a
ce bean-ul e construit, iar dependint ele injectate
@PreDestroy – nu e adnotare exclusiv a a Spring -ului, dene ste o metod a ce va
apelat a doar dup a ce bean-ul este distrus, ind util a pentru "golirea" resurselor
3.Congurare bazat a pe Java
Aceast a opt iune permite scrierea de congurat ie f ar a ajutorul XML, dar cu ajutorul
c^ atorva adnot ari bazate pe Java, dup a cum urmeaz a:
@Conguration – indic a faptul c a clasa adnotat a astfel poate  folosit a ca o surs a
de denit ii de bean-uri
@Bean – comunic a Spring -ului c a o metod a adnotat a astfel va returna un obiect
care trebuie ^ nregistrat drept un bean ^ n contextul de aplicat ie Spring .
Un alt concept interesant al Spring , de care vom uzita ^ n aplicat ia Doc-shelf este cel legat
descope -urile bean-urilor. Framework-ul pune la dispozit ie cinci astfel de scope -uri, trei dintre
ele ind disponibile doar ^ n cazul folosirii unui ApplicationContext web-aware :
19

1.Singleton – ^ n acest caz container-ul Spring IoC creaz a o singur a instant  a a obiectului
denit prin denit ia bean-ului.
2.Prototype – se creeaz a o nou a instant  a de bean a obiectului de ecare dat a c^ and se face
o cerere c atre acel bean.
3.Request – se creeaz a o nou a instant  a a bean-ului la ecare request HTTP.
4.Session – returneaz a o singur a instant  a bean-ului la ecare sesiune HTTP.
5.Global Session – returneaz a o singur a instant  a a bean-ului la ecare sesiune HTTP
global a.
Cele prezentate mai sus sunt doar c^ ateva cazuri de utilizare  si principii ale modulului Core
din cadrul acestui framework, ce vor  integrate ^ n aplicat ia pe care o propun. Pe l^ ang a
folosirea de facilit at i cu care acest modul se prezint a, dorim s a amintim  si facilit at i din cadrul
altor module, spre exemplu Spring MVC .
1.1.2.2 Spring MVC
Modulul vine cu o arhitectur a de tip model-view-controller , al aturi de numeroase componente
ce pot contribui la dezvoltarea unei aplicat ii web
exibile. Modelul MVC se bazeaz a pe
separarea diferitelor aspecte ale aplicat iei ( input logic, bussiness logic, UI logic ), acestea ind
slab cuplate. Model -ul ^ ncapsuleaz a datele  si este format din POJO-uri, partea de View e
responsabil a cu returnarea datelor  si genereaz a ^ n general output ^ n format HTML, pe care
browser-ul clientului ^ l poate interpreta, iar Controller -ul e responsabil de procesarea
cererilor utilizatorilor  si construirea de date adecvate, pe care mai apoi le va returna view-ul.
Spring MVC e conceput ^ n jurul unui DispatcherServlet , care se ocup a de toate cererile  si
r aspunsurile HTTP. Acesta trimite cererile spre controllere, pentru ca acestea s a execute
funct ionalitatea specic a. O anumit a clas a este un controller dac a este adnotat a cu
20

@Controller .
Anumite adnot ari specice Spring MVC au puterea de a simplica, de asemenea, procesul
de creare a RESTful web services , servicii web bazate pe metodele HTTP  si conceptul de
REST. Acest concept reprezint a o arhitectur a client-server bazat a pe folosirea resurselor, ind
scalabil a datorit a separ arii de responsabilit at i ^ ntre client  si server. De exemplu,
responsabilitatea unui client este s a ment in a starea unui utilizator, ^ n timp ce serverul nu
ment ine nici o stare, dar este resposabil de managementul datelor. De asemenea ^ ntre
request-uri serverul nu trebuie s a ment in a starea clientului (stateless).
Principala diferent  a ^ ntre un controller MVC tradit ional  si unul specic REST este felul ^ n
care r aspunsul HTTP e creat. ^In timp ce controller-ul MVC clasic se bazeaz a pe tehnologia
View, controller-ul MVC specic serviciilor REST doar returneaz a obiectul, iar datele sunt
trimise direct prin intermediul r aspunsului HTTP ^ n format JSON sau XML. Un controller de
servicii REST trebuie adnotat cu @RestController , adnotare ce nu face altceva dec^ at s a
^ ndeplineasc a  si s a adauge funct ionalit at i ale @Controller , respectiv @ResponseBody
(aceast a adnotare din urm a, folosit a asupra unei metode, are ca efect convertirea de c atre
Spring a valorii returnate  si trimiterea ei automat a c atre r aspunsul HTTP).
1.1.2.3 Spring Boot
Nu vom ^ ncheia aceast a sect iune f ar a a trece ^ n revist a avantaje ale folosirii Spring Boot ^ n
cadrul aplicat iilor web, acesta ind un framework special construit pentru a u sura dezvoltarea
aplicat iilor care folosesc Spring , respectiv testarea acestora. De asemenea, are avantajul de a
reduce timpul dezvolt arii  si al test arii, ^ mbun at at ind, astfel, productivitatea, prin faptul c a
evit a folosirea congur arilor XML, deci munca de congurare devine mai put in a. Este, drept
urmare, un framework pentru sisteme de build, suport^ and at^ at Maven, c^ at  si Gradle.
21

Spring Boot ofer a facilit at i pentru testarea  si procesul de deploy al aplicat iilor bazate pe
Spring . Cu ajutorul comenzii mvn spring-boot:run , Maven lanseaz a aplicat ia pe portul 8080,
similar cu felul ^ n care plugin -ulJetty funct ioneaz a. De asemenea, framework-ul ofer a
posibilitatea ca aplicat ia s a e "^ mpachetat a" ^ ntr-un  sier JAR, av^ and un server Tomcat
^ ncorporat. Folosirea liniei de comand a sau scrierea de cod Groovy pentru a benecia de ceea
ce ofer a framework-ul nu sunt necesare, acesta oferind suport  si prin intermediul unor clase
Java. Astfel c a rularea unei aplicat ii bazate pe Spring Boot se poate realiza din cadrul
mediului de dezvoltare utilizat, printr-o metod a main care apeleaz a clasa
SpringApplication  si care folose ste adnotarea @EnableAutoConguration .
1.1.3 Java Server Faces
Ce este JSF?
Java Server Faces , prescurtat JSF, este un framework folosit pentru dezvoltarea de aplicat ii
web. A fost creat de Java Community Process (JPC) format din expert i ^ n dezvoltarea de
aplicat ii web din diferite grupuri, ca: Jakarta Struts, Oracle, Sun, IBM, ATG , etc. JSF face
parte din  sabloanele Web bazate pe MVC (Model-View-Controller) design pattern. Aplicat iile
create folosind framework-ul JSF sunt u sor de dezvoltat  si de ^ ntret inut comparativ cu alte
aplicat ii create folosind JSP  siServlet .JSF ofer a:
crearea UI folosind componente standard, reutilizabile
accesarea  si manipularea componentelor UI folosind taguri JSP
salvarea st arii componentelor UI c^ and clientul face o solicitare pentru o nou a pagin a, pe
care o restaureaz a c^ and solicitarea este returnat a (asigur a persistent a st arii la nivel Web)
un model de interact iune bazat pe evenimente
22

mecanisme pentru dezvoltarea de componente proprii care separ a prezentarea
componentelor de funct ionalitate, astfel ^ nc^ at acestea s a poat a  utilizate ^ n pagini
HTML, WML, etc.
simplicarea modului de creare a IDE-urilor pentru dezvoltarea de aplicat ii Web
Framework-ul este format dintr-un set de API-uri pentru reprezentarea componentelor
interfet ei utilizatorului (UI)  si administrarea st arii lor, tratarea evenimentelor  si validarea
intr arilor, convertirea valorilor, denirea navig arii ^ n pagini, c^ at  si suport pentru
internat ionalizare  si accesibilitate. E format, de asemenea, din libr arii de taguri JSP folosite
la crearea componentelor UI.
JSF este, astfel, un framework orientat pe partea de server, nu pe partea de client. Acest
lucru ^ nseamn a c a ^ n arhitectura JSF, majoritatea evenimentelor legate de UI management
sunt tratate pe partea de server. Un exemplu de framework UI orientat pe partea de client este
Swing . O caracteristic a important a a framework-ului JSF este faptul c a se separ a tipurile de
activit at i efectuate la crearea unei aplicat ii web:
Design – editarea paginilor JSP, HTML
Dezvoltare – implementarea logicii aplicat iei
Crearea componentelor UI – componente ce vor  utilizate de designeri pentru realizarea
UI
Arhitectura – asigurarea
uxului aplicat iei, a scalabilit at ii, congur arii, etc.
Vom lista ^ n continuare caracteristici generale pe baza c arora funct ioneaz a framework-ul:
Denirea regulilor de navigare ^ ntre pagini – JSF are propriile componente care faciliteaz a
navigarea printre pagini  si ofer a posibilitatea controlului navig arii.
23

Validator – este componenta care se ocup a cu validarea datelor de intrare
Convertors – JSF converte ste valori de tip date  si numere ^ n valori ce pot  a sate cu
u surint  a ( string -uri)
Messages – folosite pentru a sarea de mesaje de success sau eroare utilizatorului
Beans – se ocup a de logica aplicat iei
Event handling – JSF simplic a tratarea evenimentelor
Internat ionalizare
Custom GUI controls – JSF ofer a un set de API-uri  si taguri associate pentru a crea forme
HTML cu interfet e complexe
^In cazul ^ n care un client face o cerere, cererea ajunge prin intermediul ret elei la server,
unde framework-ul JSF construie ste o reprezentare UI  si o a seaz a clientului ^ n mark-up
language-ul corespunz ator clientului. User-ul interact ioneaz a cu pagina web  si submite o
cerere de procesare serverului. Framework-ul JSF interpreteaz a parametri cererii, ^ i decodeaz a
 si ^ i converte ste la evenimente, apoi le propag a c atre logica de tratare a evenimentelor.
JSF este unul din framework-urile care se bazeaz a pe structura Model-View-Controller
(MVC). Ca orice alt framework bazat pe MVC, arhitectura JSF are propriul Front controller,
numit FacesServlet . MVC este un model arhitectural folosit ^ n ingineria software. El separ a
interfat a aplicat iilor web ^ n trei p art i: model, view  si controller, rezult^ and astfel o aplicat ie
unde este mai u sor de modicat aspectul vizual sau nivelele inferioare ale regulilor de business
f ar a a afecta alte nivele. Datele introduse de user, modelarea lumii externe  si feedback-ul
vizual c atre user sunt tratate separat de ecare component a a modelului. Controller-ul
interpreteaz a intr arile de la mouse  si tastatur a  si mapeaz a aceste act iuni la comenzi care sunt
trimise c atre model sau/ si view pentru a efectua schimb arile corespunz atoare. Modelul
24

prelucreaz a unul sau mai multe elemente, r aspunde la interog ari asupra st arii lui  si r aspunde
la instruct iuni de schimbare a st arii. View-ul controleaz a o zon a din suprafat a de a sat  si este
responsabil cu prezentarea datelor c atre user printr-o combinat ie de grac a  si text.
Model -ul este responsabil cu reprezentarea datelor  si a act iunilor ce opereaz a asupra
datelor de la nivelul Web al aplicat iei, ind folosit pentru a controla informat iile  si a notica
observatorii c^ and acestea se modic a. View -ul este reponsabil cu prezentarea rezultatelor
c atre utilizator  si  stie cum s a a seze cont inutul c atre utilizator. ^In plus, c^ and modelul se
modic a, view-ul automat "redeseneaz a" partea afectat a pentru a re
ecta modic arile
ap arute. Controller -ul reprezint a componenta prin care user-ul interact ioneaz a cu aplicat ia.
El prime ste informat ii de la user  si instruie ste model-ul  si view-ul s a execute act iuni bazate pe
input-ul primit. ^In principiu, controller-ul este responsabil cu maparea act iunilor efectuate de
user la r aspunsul care trebuie oferit de aplicat ie.
O aplicat ie JSF necesit a unele  siere de congurare: faces-cong.xml , respectiv web.xml .
Primul dene ste Managed Bean (clas a Java care va  creat a dinamic ^ n timpul rul arii
aplicat iei JSF, put^ and  denit a cu diferite scope-uri – Session, Request, Application sau
niciunul dintre ele – ), navigarea ^ ntre pagini web, validatorii  si convertorii. Al doilea  sier de
congurare, ce trebuie s a se reg aseasc a ^ n directorul WEB-INF al aplicat iei, se ocup a cu
specicarea faptului c a un FacesServlet e responsabil de aplicat ia JSF, acesta primind toate
cererile  si init ializ^ and componentele JSF ^ nainte ca JSP s a e a sat.
JSF ^ ndepline ste ^ n mare m asur a specicat iile pe care speciali stii  si le-au propus la
^ nceperea implement arii framework-ului, printre care amintim proprietatea de a
user-friendly , existent a unei distinct ii clare ^ ntre UI component model  si a sarea
componentelor UI folosind orice tip de client  si orice protocol  si posibilitatea  sablonului de a
lucra cu JSP, dar  si cu alte tehnologii.
25

1.2 Tehnologii pe partea de Client
C^ and se construie ste o aplicat ie, deseori aceasta are nevoie  si de o interfat  a, o sect iune care s a
comunice cu clientul. ^In cadrul aplicat iilor web aceast a delimitare ^ ntre tehnologiile pe partea
de server  si cele pe partea de client este mult mai vizibil a fat  a de alte tipuri de aplicat ii. De
aceea, ^ n continuare vom face o scurt a prezentare a tehnologiilor folosite pe partea de client.
1.2.1 PrimeFaces
Ce este PrimeFaces?
Exist a mai multe biblioteci de componente UI (de la diferit i furnizori) care pot  incluse ^ n
pagini JSF folosind noi tag-uri  si care sporesc calitatea paginilor aplicat iilor  si satisfact ia
utilizatorilor. Multe din aceste biblioteci includ  si componente cu comportare AJAX, care se
bazeaz a pe biblioteci de componente Javascript (jQuery, YUI,  s.a.m.d), cum ar  RichFaces,
IceFaces, Trinidad, Tobago sau PrimeFaces.
PrimeFaces este o astfel de bibliotec a open source, creat a de cei de la PrimeTek , care a
luat na stere ^ n anul 2008. De la aparit ie  si p^ an a acum, framework-ul a fost sust inut constant
de companii precum Oracle, iar acest lucru e observabil  si ^ n dezvoltarea  si popularitatea pe
care le-a c ap atat ^ n timp. Biblioteca prezint a un set de principii bine denite ^ n jurul c arora
este construit a, principalele ind simplitatea  si performant a. PrimeFaces e indicat a a
folosit a ^ n aplicat ii care folosesc Spring Framework  si care au nevoie de un  sablon front-end
bazat pe JSF. De asemenea, faptul c a unele biblioteci au la baz a ^ nsu si PrimeFaces , face ca
acest  sablon s a e unul sigur pentru dezvoltatori. Biblioteca PrimeFaces are un num ar mare
de componente (peste 100) compatibile cu HTML5, care suport a capabilit at i AJAX, sunt
26

responsive  si se potrivesc cu orice browser sau device moderne, ind u sor de utilizat. ^In plus,
framework-ul vine cu alte facilit at i, cum ar  PrimeFaces PUSH (bazat pe framework-ul
Atmosphere ) sau PrimeFaces Extensions (care ofer a componente avansate). Odat a ad augat
jar-ul specic bibliotecii ^ n classpath, pentru a putea ^ ncepe folosirea de componente pe care
acest framework le ofer a este de ajuns s a ad aug am namespace-ul specic ^ n cadrul paginii
c areia vrem s a ^ i cre am o interfat  a.
O simpl a pagin a de test poate  creat a ^ n felul urm ator:
Lista 1.6: Crearea unui bean printr-un sier de congurare XML
1<!D O C T Y P E html >
2<html xmlns =" http ://www. w3c . org /1999/ xhtml"
3 xmlns : h=" http :// xmlns . jcp . org / j s f /html"
4 xmlns :p=" http :// primefaces . org / ui " >
5<h :head> </h :head>
6<h :body>
7 <p: e d i t o r / >
8</h :body>
9</html>
La rulare, pagina ar trebui s a cuprind a un editor de text, marcajele ( <p:>) ind capabile
s a genereze cod Javavscript compact. Multe componente PrimeFaces corespund unor
componente JSF2 , dar au atribute ^ n plus care permit alegerea unei comport ari AJAX sau
non-AJAX. Dac a atributul ajax are valoarea False atunci butonul se comport a ca ^ n orice
aplicat ie JSF  si o nou a pagin a se transmite integral ca r aspuns la act ionarea butonului.
Totu si, o caracteristic a puternic a a PrimeFaces r am^ ane client side validation . Validarea
e un aspect de maxim a important  a ^ n cadrul unei aplicat ii, at^ at dezvoltatorii, c^ at  si
utilizatorii dorindu- si ca aceasta s a aib a loc repede  si securizat. Acest obiectiv e destul de
27

greu de realizat av^ and ^ n vedere faptul c a rapiditatea t ine de client-side, care nu ^ ndepline ste
 si securizarea, ^ n timp ce caracterul de a  secure t ine de server-side, dar acest lucru nu
garanteaz a c a validarea se va face rapid. ^In acest sens, PrimeFaces aduce ^ n prim plan client
side validation, framework ce implementeaz a API-ul de validare al JSF ^ n cadrul browserului.
Dup a cum spune  si documentat ia ocial a, acest tip de validare e caracterizat de urm atoarele
aspecte:
e compatibil cu o implementare server side
conversia  si validarea au loc pe partea de client
procesarea part ial a are suport pentru AJAX
integrarea cu validarea de bean-uri avansate
u sor de implementat convertori  si validatori specici
Prin urmare,
exibilitatea  si u surint a ^ n folosire de care d a dovad a PrimeFaces , face ca
aceast a bibliotec a JSF pentru interfet e grace s a e ^ n prezent cea mai popular a.
1.2.2 CSS
CSS1este un limbaj de stilizare care permite formatarea elementelor unui document scris
intr-un limbaj de marcare (HTML, XML etc.). Codul HTML se utilizeaz a, de obicei, pentru
plasarea cont inutului ^ n pagina WEB, detaliile legate de a sare (culori, font-uri, fundaluri,
margini, etc.) ind asigurate de elementele CSS.
CSS este conceput ^ n primul r^ and pentru a oferi posibilitatea separ arii documentului ca  si
cont inut (scris i n HTML sau un Markup Language similar) de documentul de prezentare
1Cascading Style Sheets
28

(scris ^ n CSS). Aceast a separare ^ mbun at at e ste accesibilitatea cont inutului, ofer a o mai mare

exibilitate  i asigur a un control mai simplu al modului de prezentare al elementelor HTML.
Aplicarea foilor de stil ^ n cascad a asupra codului HTML se poate face ^ n mai multe moduri:
stiluri ^ n linie, stiluri interne, stiluri externe, clase CSS. Beneciile concrete ale utiliz arii CSS
includ controlarea layout-ului documentelor dintr-o singur a pagin a de stiluri, control mai
exact al layout-ului, aplicare de layout-uri diferite pentru tipuri media diferite (ecran,
printare, etc), precum  si tehnici numeroase  si sosticate.
1.3 Alte tehnologii utilizate
1.3.1 Gradle
ANT  siMaven au ^ mp art it un real succes pe piat a Java. ANT a fost primul tool destinat
build-ului, realizat ^ n anul 2000, dezvoltat pe baza conceptului de programare procedural a.
Mai t^ arziu, a fost ^ mbun at at it cu abilitatea de a lucra cu plugin-uri  si alte dependint e cu
ajutorul Apache-Ivy . Principalul dezavantaj este formatul XML cu care sunt scrise scripturile
de build. Maven a fost introdus mai apoi, ^ n 2004, venind cu ^ mbun at at iri fat  a de ANT ,
schimb^ andu- si din structur a, dar p astr^ and formatul XML. Maven ofer a posibilitatea de a ^  si
desc arca dependint ele prin ret ea. Avantajul principal este dat de ciclul de viat  a al acestui
tool.
Ce este Gradle?
Gradle a ap arut ^ n vizorul dezvoltatorilor abia ^ n 2012. Acesta este un sistem open source de
construire  si management al proiectelor, p astr^ and cele mai bune concepte ale ANT  siMaven ,
printr-un limbaj nou introdus, denumit Groovy , ^ n locul XML-ului folosit de celelalte dou a
sisteme amintite anterior. Dintre caracteristicile tool-ului, enumer am urm atoarele:
29

1.Build-uri declarative -Gradle e disponibil cu diferite DSL-uri (Domain Specic Language)
bazate pe limbajul Groovy , tool-ul oferind elemente de limbaj declarativ, care suport a
limbaje de programare precum Java, Groovy, Scala sau Web
2.Limbaj pentru programarea bazat a pe dependint e
3.Structurarea build-ului -Gradle permite aplicarea unor principii comune de design ^ n ceea
ce prive ste build-ul
4.Scalabilitate – tool-ul poate ^ mbun at at i productivitatea, ind aplicabil at^ at pe proiecte
mici, simple, c^ at  si pentru construirea de multi-proiecte Enterprise
5.Moduri diferite de a gestiona build-urile
6.Migrare u soar a -Gradle se poate adapta cu u surint  a la orice structur a
7.Gradle Wrapper – permite execut ia de build-uri pe ma sini unde tool-ul nu este instalat
8.Open source -Gradle e un proiect open source, licent iat Apache Software License
9.Groovy – scriptul de build al Gradle e scris ^ n limbajul Groovy , special conceput pentru
proiecte Java, design-ul tool-ului ind orientat spre a  folosit drept un limbaj, nicidecum
precum un framework rigid.
Dup a cum se poate observa, Gradle ofer a opt iuni avansate ^ n felul ^ n care gestioneaz a
dependint ele. Devine posibil a declararea de dependint e importante, r am^ an^ and ^ n sarcina
tool-ului de build s a determine ce alte biblioteci trebuie declarate pentru a veni ^ n suportul
celor declarate deja. ^In concluzie, Gradle este un set de standarde  si o abordare specic a,
inedit a, ^ n dezvoltarea sistemelor software. Este un instrument capabil, care poate  ^ n acela si
timp
exibil, dar  si generator de convent ii, ^ ns a utilizat ^ n spiritul standardelor ^ n jurul c arora
a fost conceput, devine un tool puternic ce ^ nglobeaz a facilit at i ale celor ap arute ^ naintea lui.
30

1.3.2 Ghostscript
Ce este GhostScript?
Dezvoltat ^ n totalitate cu ajutorul limbajului de programare C, GhostScript reprezint a o
suit a de software-uri care ofer a:
Un interpretor pentru limbajul PostScript  si pentru formatul Adobe Portable Document;
Utilit at i pentru citirea a diferite formate rasterizate, cum ar  CMYK, GIF, JPEG, MIFF,
PBM/PGM/PPM sau PCX;
Drivere (module output) pentru o larg a varietate de sisteme precum X Windows sau
Microsoft Windows
Biblioteca Ghostscript , un set de proceduri pentru implementarea gracii  si a ltr arii ^ n
limbajul PostScrip  si ^ n PDF.
Mai simplu, putem emite ideea c a Ghostscript poate citi  siere PostScript sau PDF  si s a
se ocupe cu a sarea rezultatelor pe ecran sau de convertirea lor ^ ntr-un format ce poate
printat la o imprimant a non-PostScript. Astfel, cu ajutorul unor unelte de preview,
Ghostscript face posibil a vizualizarea sau printarea de documente ^ ntregi ori pagini izolate ale
acestora, chiar dac a ma sina de pe care se lucreaz a nu are Display PostScript sau o
imprimant a ata sat a care s a nu lucreze doar cu  siere PostScript. Tool-ul poate  folosit, de
asemenea, pentru convertirea  sierelor din format PostScript ^ n format PDF, prin intermediul
programului de conversie cu care e distribuit, denumit ps2pdf .Ghostscript poate  portat pe
diferite sisteme de operare, incluz^ and Unix, Linux, Mac OS, Microsoft Windows sau multe
altele.
31

1.3.3 Ghost4j
Ce este Ghost4j?
Ghost4j este un wrapper Java pentru API-ul Ghostscript . Principalele sale caracteristici
constau ^ n faptul c a ofer a un API orientat pe obiecte, suport integral pentru Ghostscript , un
API de nivel ^ nalt care cont ine o serie de componente (convertori, analizatori, componente
pentru randare) folosite pentru gestionarea de  siere Postscrip  si PDF, iar nu ^ n ultimul r^ and,
framework-ul vine cu suport multi-proces. ^Incep^ and cu versiunea 0.4.0, Ghost4j a introdus un
API de nivel ^ nalt, pentru a face gestiunea  sierelor mai u soar a cu ajutorul Ghostscript , acesta
ind compus din:
Documente – obiecte care reprezint a un document, de obicei de tip Postscrip sau PDF,
oferind metode de ^ nc arcare, scriere sau num arare a paginilor pe care documentul le are.
Componente – familiile de componente sunt analizatorii, convertorii, modicatorii,
componentele de randare
API-ul este binevenit pentru dezvoltatorii Java, la fel  si faptul c a Ghostscript e un tool gratuit,
ce poate  aplicat ^ n diferite scenarii din cadrul proiectelor.
32

Capitolul 2
Implementarea solut iei
2.1 Prezentare general a
Implementarea solut iei software pentru aplicat ia web Doc-shelf cuprinde o serie de "actori"
care fac posibil
ow-ul facil al acesteia, precum  si ^ ndeplinirea obiectivelor propuse.
Pornind de la nevoile clientului, ^ n momentul ^ n care browser-ul face o cerere prin
intermediul componentelor UI puse la dispozit ie de biblioteca PrimeFaces , aceast a cerere
ajunge la server, unde framework-ul JSF interpreteaz a parametri cererii, ^ i decodeaz a  si ^ i
converte ste la evenimente, pe care le trimite mai apoi c atre logica de tratare a evenimentelor.
Act iunile ce trebuie ^ ndeplinite se propag a c atre alte clase, ^ n general numite Controller , care,
la r^ andul lor, sunt ^ n str^ ans a leg atur a cu clasele ce cont in metode de accesare a datelor,
denumite Model , partea de bussiness logic ind tratat a de layer -ul ce cuprinde serviciile, nivel
care va interact iona cu sistemul local de  siere ^ n momentul upload-ului de documente
(acestea, al aturi de thumbnail -ul ec arui document, vor  stocate pe disc). Nivelul de
persistent  a e responsabil cu oferirea de operat ii de acces la date nivelului de servicii,
persistent a ind realizat a cu ajutorul platformei Solr.
33

Dup a cum se poate observa din Fig. 2.1 de mai jos, exist a un caz ^ n care cererile
browser-ului nu ajung la server prin intermediul PrimeFaces , respectiv JSF pentru
^ ndeplinirea anumitor act iuni, ci au leg atur a direct a cu Spring MVC , mai precis cu interfat a
REST . Aceste act iuni vor  reprezentate de controllere ce se vor ocupa cu gestionarea
documentelor PDF sau a thumbnail -urilor acestora. Spring Container cuprinde nivelele ^ n
cadrul c arora s-a realizat implementarea, totul ind construit ^ n jurul Spring Boot
Runtime ,plugin pentru sisteme de build, care cont ine un Embedded Tomcat .
Arhitectura aplicat iei poate  urm arit a ^ n Fig. 2.1, ind ilustrat a printr-o diagram a de
sistem, ce include nivelele  si framework-urile ce au f acut posibil a dezvoltarea bibliotecii digitale.
2.2 Congurat ia proiectului
2.2.1 Congurat ia Gradle
Pentru realizarea congurat iei de build  si asamblare a proiectului s-a pornit de la utilizarea
framework-ului Gradle , f ar a a  imperios necesar a instalarea acestuia pe ma sin a. ^In acest
sens, tool-ul ofer a Gradle Wrapper , care rezolv a problema folosirii unei versiuni vechi, ind
modalitatea recomandat a de realizare a build-ului.
Acesta se va executa, astfel, cu ajutorul comenzii gradlew clean build , lansat a din
root-ul aplicat iei. ^In urma acestei comenzi, WAR-ul (Web Application ARchive) va  generat
la locat ia build/libs/doc-shelf.war .
Congurat ia Gradle se reg ase ste ^ n  sierul build.gradle , bazat pe limbajul Groovy ,  sier
ce g azduie ste o serie de dependint e, task-uri, plugin-uri  si propriet at i de care proiectul are
nevoie pentru a funct iona corect integral. Acest  sier se g ase ste ^ n directorul p arinte al
aplicat iei  si cont ine:
34

Fig. 2.1: Diagram a de sistem
35

group = ’com.rodocea’ : grupul proiectului, Gradle utiliz^ and ^ ntotdeauna valoarea
toString() a acestuia
version = ’1.0-SNAPSHOT’ : versiunea curent a a proiectului
Blocul de script buildscript : cont ine at^ at dependint a pentru plugin -ul de Spring
Boot, c^ at  si repository -ul central Maven
sourceCompatibility  sitargetCompatibility : e specicat a versiunea pentru
compilarea surselor Java
Blocul jar: ^ n cadrul lui e specicat numele arhivei create
Blocul ext: cuprinde versiunea de JSF utilizat a
Blocul dependencies : declar a dependint ele tuturor framework-urilor folosite ^ n
implementarea aplicat iei, acest lucru realiz^ andu-se mai compact dec^ at ^ n cazul
XML-ului utilizat ^ n congurarea unui proiect Maven . Exemplu de congurare a
dependint ei pentru platforma Apache Solr : compile
’org.apache.solr:solr-solrj:5.4.1’
2.2.2 Congurat ia Solr
Solr e congurat cu ajutorul a trei  siere:
solr.xml
solrcong.xml
schema.xml
36

Odat a instalat, acesta ofer a o interfat  a grac a ce face ca administratorii sau programatorii
s a aib a acces facil la detalii de congurare, rularea interog arilor sau analiza documentelor. ^In
Solr, termenul core se refer a la un index de tip Lucene , o singur a instant  a de Solr put^ and
avea multiple core-uri cu structuri  si congurat ii diferite.
Fig. 2.2: Interfat a grac a Solr Admin
Dup a cum poate  observat ^ n gura anterioar a, instant a de Solr folose ste dou a core-uri,
doc, respectiv user , acestea j uc^ and  si rolul unor tabele din cadrul bazelor de date. Structura
lor e denit a ^ n  siere schema.xml separate.
^In continuare sunt prezentate structurile celor dou a core-uri.
Core-ul user are 3 c^ ampuri: id,name ,password , toate de tip string , cu valori truepentru
propriet at ile "stored", "indexed", respectiv "required".
37

Lista 2.1: Structura core-ului user
1<f i e l d name=" id " type=" s t r i n g " indexed=" true " stored=" true " required=" true "
multiValued=" f a l s e " / >
2<f i e l d name="name" type=" s t r i n g " indexed=" true " stored=" true " required=" true "
multiValued=" f a l s e " / >
3<f i e l d name=" password " type=" s t r i n g " indexed=" true " stored=" true " required="
true " / >
Core-ul specic documentelor, denumit doc, cont ine mai multe c^ ampuri: id,name ,title ,
author ,subject ,content type ,user id, respectiv upload date .
Lista 2.2: Structura core-ului doc
1<f i e l d name=" id " type=" s t r i n g " indexed=" true " stored=" true " required=" true "
multiValued=" f a l s e " / >
2<f i e l d name="name" type=" text ws " indexed=" true " stored=" true " / >
3<f i e l d name=" t i t l e " type=" text ws " indexed=" true " stored=" true " / >
4<f i e l d name=" author " type=" text ws " indexed=" true " stored=" true " / >
5<f i e l d name=" s u b j e c t " type=" text ws " indexed=" true " stored=" true " / >
6<f i e l d name=" content type " type=" s t r i n g " indexed=" f a l s e " stored=" true " / >
7<f i e l d name=" content " type=" t e x t g e n e r a l " indexed=" true " stored=" f a l s e " / >
8<f i e l d name=" u s e r i d " type=" s t r i n g " indexed=" true " stored=" true " / >
9<f i e l d name=" upload date " type=" tdate " indexed=" true " stored=" true " / >
2.2.3 Congurat ia Tika
Pentru a congura Tika, avem nevoie de un handler bazat pe clasa
solr.extraction.ExtractingRequestHandler ^ n  sierul de congurare
solrcong.xml .
38

Lista 2.3: Congurat ie Tika
1<requestHandler name="/update/ e x t r a c t " c l a s s=" ' org . apache . s o l r . handler .
e x t r a c t i o n . ExtractingRequestHandler " >
2<l s t name=" d e f a u l t s " >
3 <s t r name="lowernames" >true</ s t r>
4 <s t r name="fmap . s t r e a m s i z e " >s i z e</ s t r>
5 <s t r name=" u p r e f i x " >ignored </ s t r>
6</ l s t>
7<l s t name=" date . formats " >
8 <s t r>yyyyM Mdd</ s t r>
9</ l s t>
10</ requestHandler >
Parametrul lowernames e setat pe valoare de true, ceea ce ^ nseamn a c a i se comunic a
Solr-ului s a transforme ^ n litere mici toate datele pe care Tika le extrage. Al doilea
parametru indic a faptul c a, pe l^ ang a metadatele extrase de Tika,Solr-ul trebuie s a adauge  si
el m arimea ^ n octet i a  sierelor. ^In nal, este denit  si formatul dorit al datei.
2.3 Descrierea codului surs a
^In cele ce urmeaz a va avea loc o trecere ^ n revist a a principalelor pachete, clase  si resurse ce
intr a ^ n component a proiectului.
Pachetul com.rodocea.docshelf.boot
Acesta este pachetul principal al proiectului. Toate celelalte pachete sunt de fapt sub-
pachete ale acestuia. ^In cadrul acestui pachet este denit a o singur a clas a, denumit a
DocShelfApp , ce reprezint a clasa principal a a proiectului, mai precis clasa care cont ine
funct ia main .
39

Clasa com.rodocea.docshelf.boot.DocShelfApp
Dup a cum a fost ment ionat anterior, aceasta este clasa principal a a proiectului, ea
cont in^ and funct ia main ce e apelat a ^ n momentul ^ n care aplicat ia e executat a. Aceast a
funct ie utilizeaz a metoda pus a la dispozit ie de Spring Boot ,
SpringApplication.run() , av^ and ca parametri sursa ce trebuie executat a (^ n
cazul nostru chiar clasa ^ n sine, DocShelfApp.class ), al aturi de argumentele
aplicat iei, transmise de c atre metoda principal a. Metoda run() returneaz a un
ApplicationContext , care preia toate bean-urile create de aplicat ie sau automat
ad augate prin intermediul Spring Boot .
Clasa implementeaz a interfat a ServletContextInitializer , interfat  a folosit a
pentru congurarea unui context Servlet 3.0+ ^ n mod programatic. Clasele ce
implementeaz a aceast a interfat  a, iar nu WebApplicationInitializer , nu vor
putea  detectate de SpringServletContainerInitializer , clas a ce are
proprietatea de a  ^ nc arcat a, instant iat a  si de a avea metoda proprie de start apelat a
de c atre orice Servlet 3.0 ^ n momentul init ializ arii container-ului Spring (^ n cazul ^ n care
modulul spring-web e prezent ^ n classpath ).
Astfel, ServletContextInitializer devine gestionat de Spring , nu de
container-ul de Servlet, ind suprascris a metoda onStartup() , ^ n interiorul c areia se
apeleaz a metoda cu acela si nume asupra unei noi instant e de FacesInitializer .
Acesta din urm a reprezint a o clas a ce se preocup a cu ad augarea de map ari .jsfpentru
FacesServlet , ^ n cazul ^ n care nu au fost deja ad augate  si dac a  sierul
/WEB-INF/faces-cong.xml exist a. Metoda onStartup() aFacesInitializer
prime ste notic ari ^ n timpul procesului de pornire a aplicat iei web cu privire la clasele
ce sunt transmise unui ServletContainerInitializer .
40

Clasa DocShelfApp extinde clasa abstract a WebMvcConfigurerAdapter , c areia ^ i
suprascrie metoda addViewControllers() , acest lucru echival^ and cu congurarea
Spring MVC a aplicat iei. Metoda suprascris a adaug a un controller, acesta ind de fapt
view-ul ce reprezint a pagina de start (denit a ^ n home.xhtml ).
^In interiorul clasei mai sunt denite trei funct ii, toate adnotate cu @Bean , ceea ce
^ nseamn a c a ele au rolul de a produce bean-uri ce vor  gestionate de container-ul
Spring .
Prima dintre ele, loginRedirectingFilter() se ocup a cu returnarea unui ltru
special congurat pentru a preveni ca utilizatori neautorizat i s a poat a accesa anumite
view-uri (^ n cazul de fat  a este vorba despre redirect ionarea c atre pagina de home a unui
user neautenticat, care dore ste s a acceseze pagina de library, disponibil a doar
utilizatorilor logat i). De observat este faptul c a aceast a funct ie e adnotat a  si cu un
scope de tip prototype, ceea ce ^ nseamn a c a container-ul Spring IoC va creea o nou a
instant  a a bean-ului de ecare dat a c^ and un request pentru acel bean e lansat.
Urm atoarea metod a, httpSolrClient() , returneaz a o nou a instant  a de
HttpSolrClient . Prin intermediul adnot arii @Value , se seteaz a o valoare implicit a
parametrului metodei, reprezentat de URL-ul server-ului Solr, valoare ce se reg ase ste ^ n
 sierul doc-shelf.properties .
Acela si  sier de propriet at i cont ine  si calea c atre folder-ul de pe disc unde se vor stoca
^ n momentul upload-ului documentele, al aturi de thumbnail-urile lor, cale folosit a drept
parametru ^ n ultima metod a adnotat a cu @Bean din cadrul clasei,  si anume
singleFolderFileService() .
41

Aceste trei metode se reg asesc ^ n clasa principal a a aplicat iei ^ ntruc^ at denesc
comportamente importante generale. Pentru a- si putea ^ ndeplini funct iile dorite, clasa
pune la dispozit ie adnot ari ^ n acest sens. @SpringBootApplication indic a faptul c a
aceasta este una destinat a congur arilor, adnotarea ind alternativa la folosirea
^ mpreun a a altor trei: @Configuration ,@EnableAutoConfiguration  si
@ComponentScan . De asemenea, pentru a putea avea acces la  sierul de propriet at i
amintit mai sus, este necesar a o adnotare care s a ofere mediului Spring informat ii cu
privire la locat ia din proiect de unde se pot accesa anumite resurse, aceast a adnotare
ind@PropertySource("classpath:doc-shelf.properties") .
Pachetul com.rodocea.docshelf.filter
Pachetul cont ine o singur a clas a specializat a ^ n denirea de metode pe baza c arora se
realizeaz a evitarea acces arii unor resurse pentru utilizatorii care nu au drepturile necesare.
Clasa com.rodocea.docshelf.filter.LoginRedirectingFilter
Cont ine c^ ampurile:
{sessionModel , cu adnotarea @Autowired (folosit pentru a accesa informat ii cu
privire la client)
{loggedOutRedirects
{loggedInRedirects
Ultimele dou a obiecte sunt de tip Map<String, String >, ind folosite ca parametri
^ n cadrul constructorului. Clasa de fat  a e instant iat a ^ n clasa de baz a a aplicat iei, ^ n
cadrul metodei loginRedirectingFilter() adnotat a @Bean , parametri acesteia
ind ^ nlocuit i acolo cu numele view-urilor care se vor accesate  si spre care se propag a
redirect ionarea.
42

Clasa reprezint a un ltru, ^ ntruc^ at implementeaz a interfat a
javax.servlet.Filter , care include metoda doFilter() , ce are ca parametri un
request  si un response , al aturi de un lant  de ltre , instant  a a unei clase din
container-ul Servlet , ce implementeaz a interfat a FilterChain .Lant ul de ltre re
ect a
ordinea ltrelor, iar interfat a FilterChain cont ine  si ea o metod a doFilter() , care
are ca parametri un request  si un response , ind utilizat a de ecare ltru pentru a
invoca urm atoarea entitate a lant ului.
^In clasa curent a, metoda implementat a doFilter() execut a ^ n interiorul ei o alt a
metod a, filter() , ^ n cadrul c areia e apelat a metoda doFilter() a interfet ei
FilterChain descris a mai sus. Tot aici, se aplic a regulile de redirect ionare a
clientului ^ n funct ie de drepturile acestuia  si de resursele ce urmeaz a a  accesate. Acest
lucru se realizeaz a prin intermediul metodei applyRedirect() .
Pachetul com.rodocea.docshelf.dao.entity
Acest pachet cont ine denirea structurii entit at ilor cu care aplicat ia va opera.
Clasa com.rodocea.docshelf.dao.entity.IdEntity
Este clas a de baz a, ce va  extins a at^ at de c atre entitatea UserEntity , c^ at  si de c atre
entitatea DocEntity ,  si ^ n cadrul c areia ^ ncepe utilizarea bibliotecii SolrJ , prezentat a
^ n primul capitol.
Clasa cont ine un singur c^ amp protected , de tip String , denumit id, asupra c aruia
se aplic a adnotarea specic a SolrJ ,@Field , adnotare ce poate  la fel de bine aplicat a
asupra unui setter. Aceasta are rolul de a mapa obiectul ( POJO -ul) cu tipurile
cunoscute de c atre Solr, ce au fost declarate ^ n  sierul de congurare al acestuia,
schema.xml .
43

Clasa com.rodocea.docshelf.dao.entity.UserEntity
Dene ste entitatea UserEntity ^ n aceea si manier a, extinz^ and ^ ns a clasa IdEntity ,
de la care mo stene ste c^ ampul id. Cont ine c^ ampurile private name  sipassword , de tip
String , de asemenea adnotate cu @Field .
Clasa com.rodocea.docshelf.dao.entity.DocEntity
Creeaz a POJO-ul DocEntity , care cont ine urm atoarele c^ ampuri private, adnotate cu
@Field :
{name , de tip String
{title , de tip String
{author , de tip String
{subject , de tip String
{type , de tip String
{userId , de tip String
{uploadDate , de tip Date
^In cazul c^ ampurilor type ,userId , respectiv uploadDate , s-a ad augat adnot arii un
nume, acesta ind un alias echivalent cu numele ce a fost denit ^ n cadrul schema.xml
pentru c^ ampuri ( content type ,user id, respectiv upload date , dup a cum poate
 urm arit ^ n fragmentul de cod urm ator):
44

Lista 2.4: Snippet DocEntity.java
1@Field ( " content type " )
2private String type ;
3
4@Field ( " u s e r i d " )
5private String userId ;
6
7@Field ( " upload date " )
8private Date uploadDate ;
Pachetul com.rodocea.docshelf.dao.util
Cont ine o singur a clas a adjuvant a ^ n procesul de interogare  si returnare a entit at ilor
asupra c arora se efectueaz a diverse operat ii:
Clasa com.rodocea.docshelf.dao.util.ResultsWrapper
Reprezint a un wrapper generic ce cuprinde urm atoarele c^ ampuri private:
{results , list a generic a de rezultate ce va  folosit a, spre exemplu, ^ n metode ce
se vor ocupa de c autarea anumitor documente  si returnarea lor, aceasta
reprezent^ and rezultatele ^ ntoarse cu succes ^ n funct ie de anumite criterii, cum ar
num arul rezultatelor stabilit de c atre utilizator
{totalResults , de tip long , reprezent^ and num arul total al rezultatelor care
^ ndeplinesc un anumit query
{startIndex , de tip long , ind indexul de la care e realizat a returnarea
rezultatelor
^In afar a de metodele de get specice c^ ampurilor anterior prezentate, clasa mai
cuprinde dou a metode: getSingleResult() , care returneaz a doar primul rezultat al
45

listei results , ^ n cazul ^ n care aceasta nu e null sauempty , respectiv funct ia
generic a emptyResults() , ce returneaz a un obiect ResultsWrapper gol. Aceasta
este o bun a practic a, ^ ntruc^ at se evit a aparit ia unui NullPointerException  si
veric arile suplimentare la nivel de controller, cum s-ar  putut ^ nt^ ampla ^ n cazul ^ n
care metoda ar  returnat direct null .
Pachetul com.rodocea.docshelf.dao
Pachetul cont ine interfet ele DAO specice celor dou a entit at i principale cu care lucreaz a
aplicat ia.
Interfat a com.rodocea.docshelf.dao.DaoIF
Interfat  a generic a, ce restrict ioneaz a tipurile de date cu care lucreaz a, acestea ind
reprezentate de obiecte de tip IdEntity . Declar a metodele ce pot arunca
SolrServerException ^ n cazul ^ n care apar probleme ^ n comunicarea cu Solr sau
IOException :
{public T findById(String id)
{public T createOrUpdate(T entity, boolean autoCommit)
{public void delete(T entity, boolean autoCommit)
{public void commit()
Interfat a com.rodocea.docshelf.dao.UserDaoIF
Extinde interfat a DaoIF , tipul efectiv de date ind reprezentat de entitatea
UserEntity . Dene ste metoda findByName() , care prime ste ca parametru un
String  si returneaz a un obiect de tip UserEntity .
46

Interfat a com.rodocea.docshelf.dao.DocDaoIF
Extinde, de asemenea, interfat a DaoIF , ^ ns a ^ n cazul de fat  a invocarea clasei generice
e realizat a folosind tipul DocEntity ^ n locul tipului formal de date. Declar a metode
pentru indexare, c autare a documentelor ^ n funct ie de utilizatorul care le-a ^ nc arcat sau
pentru operat ia de search. ^In ordinea prezentat a, acestea sunt:
{public DocEntity index(String id, String name, String
userId, byte[] contents)
{public ResultsWrapper<DocEntity> findByUser(String userId,
int start, int rows)
{public ResultsWrapper<DocEntity> search(String query,
String fields, int start, int rows)
Pachetul com.rodocea.docshelf.dao.impl
Acest pachet cont ine implement arile concrete ale interfet elor DAO.
Clasa com.rodocea.docshelf.dao.impl.AbstractSolrDao
Este o clas a abstract a ce implementeaz a ^ ntr-o manier a generic a unele dintre cele mai
comune act iuni ce se pot efectua asupra obiectelor. Cont ine urm atoarele c^ ampuri
protected :
{solrClient , de tip HttpSolrClient , implementare a SolrClient care
comunic a direct cu Solr prin intermediul unei cereri HTTP; c^ ampul este adnotat
cu@Autowired , ceea ce ^ nseamn a c a Spring este cel care rezolv a dependint ele
dintre bean-uri, f ar a a  nevoie de o instat iere explicit a
{idGenService , de tip IdGenServiceIF , serviciu ce se ocup a de generarea unor
id-uri unice  si care urmeaz a s a e descris ^ n sect iunea care cuprinde pachetul din
care acesta face parte; c^ ampul este, de asemenea, adnotat cu @Autowired
47

{coreName , de tip String , care dene ste numele core-ului Solr
{entityClass , de tip Class <T>, ce reprezint a clasa specic a entit at ii
Pe l^ ang a metode generice ce se ocup a cu setarea id-ului entit at ilor sau vericarea
faptului c a o entitate are idsetat, clasa cont ine o metod a queryAndWrap() , ce
prime ste drept parametru un SolrQuery . Pe baza acestui query  si a c^ ampului
coreName , care reprezint a colect ia Solr ce trebuie interogat a, se construie ste un
r aspuns, de tip QueryResponse , care, la r^ andul s au, este utilizat pentru crearea unui
obiect de tip SolrDocumentList , list a de documente Solr returnate ^ n urma c aut arii
efectuate pe baza query-ului, ^ n core-ul specicat. Aceast a list a include informat ii
precum num arul total de documente care ^ ndeplinesc cererea clientului sau indexul de la
care a pornit c autarea, informat ii ce vor  folosite ^ n crearea unei noi instant e a
wrapper-ului ResultsWrapper , care va  returnat de c atre metoda de la care am
pornit, queryAndWrap() .
Clasa curent a are proprietatea de a implementa ^ n mod generic interfat a DaoIF . Astfel,
cele patru metode ale interfet ei sunt implementate dup a cum urmeaz a:
^In interiorul metodei findById() , cu parametrul id, este apelat a  si returnat a metoda
descris a mai sus, denumit a queryAndWrap() , al c arui parametru reprezent^ and query-ul
ind construit inline, prin instant ierea unui nou SolrQuery :new SolrQuery("id:
" + id)
^In metoda createOrUpdate() se veric a init ial existent a unui id, iar ^ n cazul ^ n
care acesta nu exist a, entitatea e populat a cu unul valid. Urmeaz a apoi ad augarea unui
bean (convertit ^ ntr-un SolrInputDocument ) ^ n cadrul colect iei Solr specicate de
c atre coreName , procesul de commit ^ n cazul ^ n care parametrul de tip boolean al
metodei este true , iar ^ n nal se face returnarea entit at ii nou create sau modicate.
48

Funct ia delete() apeleaz a metoda deleteById() a c^ ampului solrClient doar
dup a vericarea existent ei unui id, iar dup a  stergere realizeaz a commit-ul, doar dac a
parametrul ei boolean autoCommit e setat pe true .
Ultima metod a implementat a este commit() , ^ n cadrul c areia este apelat a metoda cu
acela si nume specic a solrClient , care are ca parametru colect ia Solr la care
commit-ul trebuie s a e trimis.
Clasa com.rodocea.docshelf.dao.impl.UserSolrDao
Extinde AbstractSolrDao <UserEntity >, contructorul superclasei ind invocat ^ n
clasa curent a  si implementeaz a interfat a UserDaoIF , c areia ^ i implementeaz a metoda
findByName() , metod a ^ n interiorul c areia e apelat a  si returnat a funct ia
queryAndWrap() , de aceast a dat a aceasta av^ and ca  si parametru un SolrQuery
bazat pe c^ ampul name :new SolrQuery("name:" + name)
Clasa com.rodocea.docshelf.dao.impl.DocSolrDao
Extinde  si ea AbstractSolrDao <UserEntity >, av^ and constructorul superclasei
invocat cu valori specice clasei de fat  a. Prin implementarea interfet ei DocDaoIF , se
suprascriu metodele denite de c atre aceast a interfat  a.
Prima dintre ele, metoda index() , se ocup a cu indexare documentelor ^ n Solr, ind
ilustrat a ^ n cele ce urmeaz a:
49

Lista 2.5: Metoda index() a clasei DocSolrDao.java
1@Override
2public DocEntity index ( final String id , final String name , final String
userId , final byte [ ] contents ) throws SolrServerException , IOException
f
3 final ContentStreamUpdateRequest indexRequest = new
ContentStreamUpdateRequest ( "/update/ e x t r a c t " ) ;
4 indexRequest . addContentStream ( new ContentStreamBase . ByteArrayStream (
contents , name) ) ;
5 indexRequest . setParam ( " l i t e r a l . id " , id ) ;
6 indexRequest . setParam ( " l i t e r a l . name" , name) ;
7 indexRequest . setParam ( " l i t e r a l . u s e r i d " , userId ) ;
8 indexRequest . setParam ( " l i t e r a l . upload date " , " N O W " ) ;
9 indexRequest . setParam ( "commit" , " true " ) ;
10
11 final NamedList <Object >indexResponse = s o l r C l i e n t . request ( indexRequest
, coreName ) ;
12
13 LOGGER. i n f o ( " Indexing response : " + indexResponse . t o S t r i n g ( ) ) ;
14
15 return findById ( id ) ;
16g
^In snippet-ul anterior, indexRequest e un obiect ce gestioneaz a funct ionalitatea de
baz a a ^ nc arc arii unui  sier ^ n Solr, parametrul /update/extract pe care ^ l prime ste
la instant iere reprezent^ and URL-ul la care trebuie trimis content stream -ul c atre Solr,
handler congurat ^ n cadrul solrconfig.xml . Dup a cum se poate observa, asupra
indexRequest se seteaz a prin intermediul setParam() anumite valori, structura
"literal. " denind o valoare pentru un nume de c^ amp specicat. Astfel,
c^ ampurilor specicate dup a aceast a structur a li se atribuie valorile parametrilor funct iei
index() , respectiv valoarea "NOW" ^ n cazul datei (pentru persistent a datei la care
50

documentul a fost uploadat)  si "true" (pentru a se creea commit-ul). Request-ul
urmeaz a a  procesat, iar entitatea de tip DocEntity returnat a ^ n funct ie de id-ul
s au.
Metoda findByUser() returneaz a rezultatele ^ n funct ie de un query bazat pe
user id, aici set^ andu-se de asemenea  si indexul de la care porne ste c autarea, num arul
de rezultate ce se doresc a  returnate, dar  si sortarea descresc atoare, ^ n funct ie de data
la care s-a indexat documentul.
Ultima metod a, cea destinat a c aut arii, se ocup a de returnarea rezultatelor pe baza unui
query care cont ine  si specicat ii referitoare la parser-ul de interogare folosit, ^ n cazul
curent ind vorba despre parser-ul eDisMax . Query-ului i se seteaz a, totodat a, c^ ampuri
pe baza c arora se realizeaz a c autarea, ce e efectuat a ^ ntr-o ordine descresc atoare ^ n
funct ie de scorul acestor eld-uri.
Pachetul com.rodocea.docshelf.service
Cuprinde interfet ele specice service-urilor.
Interfat a com.rodocea.docshelf.service.IdGenServiceIF
Specic a metoda generateId() , care va genera un id unic la ecare apel.
Interfat a com.rodocea.docshelf.service.HashServiceIF
Declar a metoda hash() , destinat a securiz arii parolelor utilizatorilor prin aplicarea unei
funct ii hash.
Interfat a com.rodocea.docshelf.service.PdfThumbnailServiceIF
51

Metoda cont inut a, generateThumbnail() , e destinat a gener arii thumbnail-urilor
pentru documentele ^ n format PDF .
Interfat a com.rodocea.docshelf.service.UserServiceIF
Cuprinde metode ce vor  folosite ^ n procesul de login (passwordsMatch() ,
login() ) sau ^ n cel de sign up a utilizatorilor ( usernameExists() ,
createUser() ).
Interfat a com.rodocea.docshelf.service.UploadServiceIF
Cont ine declarat ii de metode utilizate ^ n momentul upload-ului de  siere digitale,
acestea ind upload() ,confirmUpload() , respectiv cancelUpload() .
Interfat a com.rodocea.docshelf.service.FileServiceIF
Metodele sale sunt ^ n str^ ans a leg atur a cu procesul de upload, ind folosite pentru
interact iunea cu sistemul local de  siere, unde vor  stocate documentele indexate:
save() ,fetch() ,delete() .
Interfat a com.rodocea.docshelf.service.DocumentRetrievalServiceIF
Cuprinde metode de gestiune a documentelor indexate, precum:
getDocumentById() ,getDocumentsInLibrary() ,searchDocuments() .
Interfat a com.rodocea.docshelf.service.DocumentEditServiceIF
Interfat a cont ine o singur a metod a folosit a pentru editarea metadatelor unui document.
52

Pachetul com.rodocea.docshelf.service.impl
Acest pachet cont ine implement arile interfet elor enumerate anterior. ^In general, clasele
cont inute ^ n acest pachet sunt adnotate cu @Service , adnotare specic a Spring , ce
indic a faptul c a avem de a face cu clase de tip Service.
Clasa com.rodocea.docshelf.service.impl.UuidGenerationService
Implementeaz a interfat a IdGenServiceIF  si, implicit, metoda acesteia
generateId() , folosindu-se de clasa UUID din pachetul java.util pentru
generarea unui identicator unic ^ n mod aleatoriu.
Clasa com.rodocea.docshelf.service.impl.Md5HashGenerator
Implementeaz a metoda hash() declarat a ^ n interfat a HashServiceIF , utiliz^ and
clasa specic a Spring denumit a DigestUtils pentru a cripta un String dat (^ n
cazul nostru, parola) prin intermediul MD5.
Clasa com.rodocea.docshelf.service.impl.GhostscriptThumbnailGenerator
Clasa implementeaz a generateThumbnail() , metod a ^ n cadrul c areia sunt folosite
facilit at i puse la dispozit ie de API-ul Ghost4j . E init ializat  si ^ nc arcat documentul de tip
PDFDocument pe baza unui InputStream  si se preg ate ste setup-ul pentru randarea
imaginii (setarea rezolut iei, a gradului de "netezire" a imaginii). Sunt folosite facilit at ile
clasei ImageIO din pachetul javax.imageio , specializat a ^ n lucrul cu imaginile,
pentru a transmite imaginea rezultat a unui OutputStream .
Clasa com.rodocea.docshelf.service.impl.UserServiceImpl
Cont ine dou a c^ ampuri @Autowired , unul de tip UserDaoIF , cel alalt de tip
53

HashServiceIF , pe care le folose ste ^ n implementarea metodelor din superclas a.
Astfel, ^ n cazul metodei createUser() , o nou a instant  a de UserEntity este creat a,
asupra ei ind setate username -ul, respectiv valoarea dup a aplicarea MD5 asupra
password -ului ^ n clar ( username , respectiv password ind, de fapt, parametri
metodei), ^ ncerc^ andu-se crearea unui nou utilizator prin executarea metodei
createOrUpdate() , chemat a de c^ ampul de tip UserDaoIF .^In metoda login() , se
^ ncearc a g asirea utilizatorului ^ n funct ie de nume, parola ^ n clar ind hash-uit a cu
ajutorul funct iei puse la dispozit ie ^ n acest sens ^ n cadrul HashServiceIF . Dup a
vericarea faptului c a valoarea dup a aplicarea MD5 asupra parolei ^ n clar e egal a cu
valoarea parolei salvate pentru utilizatorul care ^ ncearc a s a se autentice, utilizatorul e
returnat.
Clasa com.rodocea.docshelf.service.impl.SingleFolderFileService
E clasa ce gestioneaz a interact iunile cu sistemul local de  siere, instant a ei ind folosit a
^ n clasa principal a a aplicat iei, DocShelfApp , unde e returnat a de c atre metoda care
se ocup a cu crearea bean-ului Spring , de tip FileServiceIF . Cont ine un singur c^ amp
folder de tip String , reprezent^ and folder-ul de pe disc unde vor  salvate
documentele  si imaginile (thumbnail-urile) specice lor la upload. Metoda
generateFileName() , cu parametri de tip String id , respectiv type , are rolul de
a genera numele  si extensia  sierelor, numele const^ and ^ n id-ul specic entit at ii, iar
extensia va  de tip pdf pentru documente sau png ^ n cazul thumbnail-urilor. Clasa
implementeaz a metode de save() ,fetch()  sidelete() , ^ n cadrul c arora sunt
utilizate facilit at i ale clasei FileOutputStream pentru scrierea de date ^ n cadrul unui
 sier, respectiv ale clasei FileInputStream pentru realizarea deschiderii unui  sier
^ nspre a  citit.
54

Clasa com.rodocea.docshelf.service.impl.MultiStepUploadService
Upload-ul documentelor este un proces ^ n component a c aruia se reg asesc mai mult i pa si.
^In prim a faz a, documentul al aturi de thumbnail-ul s au sunt aduse pe server  si salvate ^ n
 sierul storage de pe disc, acest lucru realiz^ andu-se prin implementarea metodei
upload() din clasa curent a, unde e apelat a metoda save() specic a serviciului
specializat ^ n lucrul cu  siere, metod a apelat a at^ at pentru  siere, c^ at  si pentru
thumbnail-urile lor. ^In acest moment utilizatorului i se ofer a dou a variante: e anuleaz a
act iunea de upload precedent a, e continu a procesul, conrm^ andu-l, ceea ce implic a
persistarea datelor ajunse pe server. Pentru anularea act iunii, clasa curent a pune la
dispozit ie metoda cancelUpload() , care realizeaz a  stergerea  sierelor PDF  siPNG
salvate pe disc, prin apelarea metodei delete() implementat a ^ n cadrul serviciului
FileServiceIF , ^ n timp ce pentru indexarea datelor ^ n Solr, metoda
confirmUpload() aduce, prin intermediul serviciului FileServiceIF , un
InputStream ce va  convertit la un byte array, acesta din urm a ind folosit al aturi
de parametri precum user -ul,fileId -ul  si fileName -ul ^ n procesul de indexare.
Clasa com.rodocea.docshelf.service.impl.DocumentRetrievalServiceImpl
Cont ine implement arile metodelor getDocumentById() ,
getDocumentsInLibrary() , respectiv searchDocuments() , unde sunt executate
metodele specice ec areia, reg asite la nivelul DAO al entit at ilor de tip document.
Clasa com.rodocea.docshelf.service.impl.DocumentEditServiceImpl
^In cadrul ei se reg ase ste o singur a metod a ce realizeaz a editarea unui document, prin
apelarea metodei createOrUpdate() prezent a la nivelul de persistent  a.
55

Pachetul com.rodocea.docshelf.model
Aici se reg asesc clasele de tip Model , responsabile cu reprezentarea  si accesarea datelor.
Acestea sunt:
Clasa com.rodocea.docshelf.model.UserModel
Clasa este adnotat a cu @Component , adnotare de Spring ce marcheaz a clasa ca ind
un bean, ^ n a sa fel ^ nc^ at mecanismul denumit component-scanning s a o poat a
prelua  si aduce ^ n cadrul application context . Se observ a, de asemenea, prezent a
adnot arii @Scope(WebApplicationContext.SCOPE REQUEST) , ceea ce ^ nseamn a
c a pentru ecare request HTTP al clientului, se va crea o nou a instant  a a bean-ului
curent. Clasa cont ine urm atoarele c^ ampuri pentru modelarea unei entit at i de tip
UserEntity , c^ ampuri ce vor intra ^ n realizarea de act iuni precum crearea unui nou
utilizator:
{username : numele de utilizator ( String )
{password : parola ( String )
{rePassword : parola de conrmare ( String )
Clasa com.rodocea.docshelf.model.SessionModel
Aceast a clas a va  folosit a ^ n procesul de login , din acest motiv ind adnotat a cu un
session scope , ceea ce asigur a o singur a instant iere a bean-ului pe ^ ntreaga durat a de
viat  a a sesiunii utilizator. Totu si, ^ n acest caz se ive ste o problem a comun a, dat a de faptul
c a bean-ul SessionModel va trebui folosit ^ n cadrul controller-ului pentru login , care
nu se dore ste a  session scoped . Pentru a rezolva aceast a problem a, Spring ofer a
un mecanism bazat pe proxy , astfel c a bean-ul session scoped va putea  utilizat
^ n cadrul unei clase adnotate cu un scope diferit. Pentru a utiliza un asemenea proxy ,
adnotarea se modic a dup a cum urmeaz a:
56

@Scope(scopeName = WebApplicationContext.SCOPE SESSION,
proxyMode = ScopedProxyMode.TARGET CLASS)
Acest model cont ine un singur obiect de tipul UserEntity  si ofer a o metod a adnotat a
cu@PreDestroy , ^ n care obiectul prime ste valoarea null , ind golit din container.
Clasa com.rodocea.docshelf.model.UploadModel
E adnotat a cu un scope ce nu apart ine framework-ului Spring , ci reprezint a un plugin cu
ajutorul c aruia un bean poate suporta un JSF view scope . Astfel, durata de viat  a a unui
bean adnotat cu @SpringScopeView va  echivalent a cu cea a unui view JSF. Clasa
cont ine c^ ampurile:
{id: id-ul  sierului ^ nc arcat ( String )
{fileName : numele  sierului ^ nc arcat ( String )
Clasa com.rodocea.docshelf.model.SearchModel
Wrapper ce ^ nglobeaz a eld-urile ^ n funct ie de care se poate realiza operat ia de c autare,
acestea ind:
{query : query-ul specicat ( String )
{nameOrTitle : documentele pot  c autate e ^ n funct ie de titlu (dac a apare printre
metadate), e ^ n funct ie de un nume setat de c atre utilizator ( boolean )
{author : c autare dup a autor ( boolean )
{content : c autare dup a cont inut ( boolean )
{myDocs : c autarea se realizeaz a doar ^ n cadrul  sierelor utilizatorului autenticat,
^ n cazul ^ n care valoarea c^ ampului e setat a pe true (boolean )
57

{excludeWords : se face o c autare a documentelor care nu cont in cuvintele
specicate prin intermediul acestui c^ amp ( String )
Metoda clear() , adnotat a cu @PostConstruct (ceea ce indic a faptul c a aceasta va
 invocat a dup a ce mecanismul de dependency injection a avut loc), seteaz a valorile
c^ ampurilor la valorile implicite, ^ n cazul unei noi c aut ari s a nu e posibil a p astrarea
datelor cu care s-a efectuat vechea c autare, bean-ul av^ and un session scope .
Clasa com.rodocea.docshelf.model.ResultsModel
Aceast a clas a intr a  si ea ^ n procesul de c autare, cont in^ and o list a de obiecte de tip
DocEntity , unde se vor seta documentele ce au fost g asite ^ n urma unei operat ii de
c autare.
Clasa com.rodocea.docshelf.model.PaginationModel
Clas a implicat a tot ^ n search-ul de documente, ofer a c^ ampuri cu valori implicite pentru
realizarea pagin arii, utilizat a ca urmare a procesului de c autare. Aceste valori includ
num arul de documente ce vor  a sate pe pagin a, num arul total de rezultate  si indexul
paginii de la care rezultatele sunt a sate. De asemenea, clasa include metode pentru
realizarea increment arii, respectiv decrement arii num arului curent al paginii, returnarea
num arului curent al indexului sau a num arului total de pagini, precum  si metoda
clear() , care seteaz a c^ ampurile clasei la valori implicite.
Clasa com.rodocea.docshelf.model.EditModel
Aceast a clas a det ine un singur c^ amp de tip DocEntity , ce urmeaz a a  gestionat prin
intermediul unui controller ce se ocup a de editarea documentelor. Se observ a, din nou,
utilizarea scope-ului JSF view scope .
58

Clasa com.rodocea.docshelf.model.ViewModel
La fel ca modelul anterior, acesta cont ine tot o entitate de tip DocEntity , folosit a de
aceast a dat a pentru popularea paginii de view , destinat a acces arii documentelor
indexate.
Pachetul com.rodocea.docshelf.holder
Cont ine clase folosite ^ n procesul de search  si returnare a documentelor, ce specic a
modul ^ n care query-urile sunt construite sau determin a c^ ampurile pe baza c arora e
realizat a c autarea.
Clasa abstract a com.rodocea.docshelf.holder.SearchData
Declar a urm atoarele c^ ampuri:
{WHITESPACE PATTERN : folosit ^ n determinarea query-ului ( Pattern )
{MINTERM SIZE : prime ste o valoare default 3, aceasta reprezent^ and num arul minim
de litere din care un termen folosit pentru c autare poate  format ( int)
{NAME ORTITLE : parametru ce intoduce dou a eld-uri, name  sititle , ecare
av^ and aplicat un factor de boost pentru a cre ste sau a sc adea relevant a c^ ampurilor
^ n cadrul query-ului; astfel, c^ ampurilor name  sititle le este asignat un boost
egal de 100, ceea ce ^ nseamn a c a factorii celor dou a eld-uri sunt la fel de important i
^ n cadrul query-ului pentru returnarea de rezultate ( String )
{AUTHOR : factorul de boost al acestuia este de 75, mai mic dec^ at ^ n cazul numelui
sau titlului corespunz ator documentului ( String )
{CONTENT : are un factor de boost mult mai slab, de 0.1  si se refer a la relevant a
c aut arii ^ n cadrul cont inutului unui document, ^ n funct ie de termenul de c autare
specicat de c atre utilizator ( String )
{query : query-ul determinat pe baza input-ului utilizatorului ( String )
59

{fields : c^ ampurile pe baza c arora e efectuat a c autarea ( String )
Clasa cont ine metode folosite ^ n construct ia unui query, cum ar  appendAnd() (are
ca parametru un StringBuilder , c aruia ^ i adaug a operatorul "AND" dac a builder-ul
nu e de lungime zero), appendUserClause() (adaug a query-ului id-ul utilizatorului
curent) sau appendTerm() , metod a abstract a implementat^in clasa ce o extinde pe
cea de fat  a.
Principalele metode ale clasei sunt determineQuery() , respectiv
determineFields() . Prima instant iaz a un StringBuilder , c aruia ^ i adaug a
termenii pozitivi reprezentat i de input-ul clientului ^ n caz c a sunt valizi, apoi termenii
negativi reprezentat i de cuvintele excluse ^ n caz ca exist a  si sunt valizi, iar ^ n nal, dac a
proprietatea myDocs din clasa SearchModel e setat a pe true , iar utilizatorul
autenticat, se adaug a la query  si id-ul acestuia. determineQuery() returneaz a
reprezentarea String a obiectului de tip StringBuilder .^In aceea si manier a,
funct ia determineFields() construie ste un obiect de tip StringBuilder , la care
adaug a, dac a valoarea c^ ampurilor din SearchModel etrue , eld-urile specice
acestora, declarate ^ n deschiderea clasei: NAME ORTITLE ,AUTHOR  siCONTENT , iar
apoi returneaz a reprezentarea String a acestui obiect compus.
Cele dou a metode intr a ^ n component a constructorului clasei, dup a cum poate  observat
mai jos:
Lista 2.6: Constructorul clasei abstracte SearchData.java
1public SearchData ( final SearchModel searchModel , final UserEntity user ) f
2 query = determineQuery ( searchModel , user ) ;
3 f i e l d s = determineFields ( searchModel ) ;
4g
60

Clasa com.rodocea.docshelf.holder.AproxSearchData
Extinde clasa abstract a SearchData , constructorul s au invoc^ andu-l pe cel al
superclasei, ilustrat anterior. E implementat a metoda abstract a appendTerm() , care
adaug a funct ionalit at i de negare query-ului (c^ and este cazul, prin ad augarea la obiectul
de tip StringBuilder aString -ului "-")  si de realizare a c aut arii ^ ntr-un mod
wildcard (prin ad augarea la builder a termenului dup a care se efectueaz a c autarea, apoi
aString -ului "*").
Lista 2.7: Metoda appendTerm() implementat a ^ n clasa AproxSearchData.java
1@Override
2protected void appendTerm ( final S t r i n g B u i l d e r queryBuilder , final String
term , final boolean exclude ) f
3 i f( exclude )f
4 queryBuilder . append ( " " ) ;
5g
6
7 queryBuilder . append ( term ) . append ( " " ) . append ( " " ) ;
8g
Pachetul com.rodocea.docshelf.controller
Pachetul cont ine clasele de tip controller , al c aror rol este acela de a ^ ndeplini act iuni
prin procesarea cererilor utilizatorilor  si de a construi date adecvate.
Clasa abstract a com.rodocea.docshelf.controller.AbstractController
Cont ine o serie de implement ari de metode specice JSF, respectiv PrimeFaces , ce vor
putea  executate din cadrul metodelor prezente ^ n restul claselor de tip Controller
(toate adnotate cu @Component  si av^ and un scope de tip request ), ce extind clasa
61

curent a  si care urmeaz a a  trecute ^ n revist a ^ n cele ce urmeaz a:
Clasa com.rodocea.docshelf.controller.SignUpController
Are urm atoarele c^ ampuri adnotate @Autowired :
{userModel , de tip UserModel
{userService , de tip UserServiceIF
C^ ampurile vor  folosite ^ n cadrul metodei createUser() , utilizat a pentru crearea
unui nou utilizator. Comunicarea modelului cu view-ul face posibil ca, ^ n momentul
trimiterii request-ului de c atre client pentru crearea utilizatorului, modelul s a e deja
populat cu datele introduse de client. Astfel, userModel e folosit pentru accesarea
eld-urilor username ,password , respectiv rePassword , asupra c arora se aplic a
mai ^ nt^ ai valid ari (validare pentru ""saunull , pentru egalitatea celor dou a parole  si
vericare ca nu cumva username -ul s a existe deja). Abia dac a aceste valid ari trec cu
succes, se utilizeaz a userService pentru crearea unui nou utilizator  si indexarea lui
^ nSolr.
Clasa com.rodocea.docshelf.controller.LoginController
Cont ine c^ ampurile @Autowired :
{loginModel , de tip LoginModel
{userService , de tip UserServiceIF
{sessionModel , de tip SessionModel
Cu ajutorul lor, sunt construite metodele login()  silogout() .^In cazul primei
metode, ^ nainte ca user-ul s a e setat pe sesiune  si redirect ionat c atre pagina de start a
aplicat iei, e necesar a validarea de ""saunull pentru username  sipassword , iar
62

apoi autenticarea prin intermediul serviciului userService .^In cazul metodei de
delogare, user-ul e scos de pe sesiune, se realizeaz a un update pe form , iar clientul e
redirect ionat spre pagina de start, home.xhtml .
Clasa com.rodocea.docshelf.controller.UploadController
Cont ine membri @Autowired :
{sessionModel , de tip SessionModel
{uploadModel , de tip UploadModel
{idService , de tip IdGenServiceIF
{uploadService , de tip UploadServiceIF
^In component a ei intr a trei metode. handleFileUpload() , cu parametrul specic
PrimeFaces FileUploadEvent , ^ ncarc a pe server documentul clientului, set^ and id-ul
 sifileName -ul corespunz atoare c^ ampului uploadModel .Id-ul e generat prin
intermediul serviciului idService , iar numele  sierului e extras prin intermediul
metodei getFileName() a clasei org.primefaces.model.UploadedFile .
Metoda confirmFileUpload() apeleaz a metoda serviciului uploadService care
se ocup a cu indexarea ^ n Solr a documentului, iar pentru a anula indexarea acestuia e
folosit a funct ia cancelFileUpload() , ce apeleaz a la r^ andul ei metoda
cancelUpload() corespunz atoare aceluia si serviciu.
Clasa com.rodocea.docshelf.controller.EditController
Det ine c^ ampurile @Autowired :
{editModel , de tip EditModel
{documentRetrieval , de tip DocumentRetrievalServiceIF
63

{editService , de tip DocumentEditServiceIF
Metoda obtainDoc() e folosit a drept listener ^ n pagina xhtml specic a view-ului
care se ocup a cu editarea documentelor, acest lucru ind posibil printr-un event de
tipul preRenderView pentru obt inerea documentului selectat ^ nainte ca modalul
corespunz ator edit arii s a e a sat, cu ajutorul unui parametru docId setat pe butonul
care lanseaz a request-ul user-ului pentru editare. Pentru editarea documentului  si
transmiterea schimb arilor pe server e utilizat a metoda updateDocument() , care
folose ste serviciile puse la dispozit ie de editService pentru update-ul documentului
curent.
Clasa com.rodocea.docshelf.controller.ViewController
C^ ampurile sale @Autowired sunt:
{viewModel , de tip ViewModel
{documentRetrieval , de tip DocumentRetrievalServiceIF
Ca  si controller-ul precedent, cont ine o metod a obtainDoc() apelat a cu un event
preRenderView . Metoda preia id-ul specic documentului ce urmeaz a a  accesat  si
cu ajutorul service-ului documentRetrieval , seteaz a documentul g asit ^ n funct ie de
id-ul curent, ^ nainte ca pagina de vizualizare a acestuia s a se deschid a.
Clasa com.rodocea.docshelf.controller.SearchController
Aceasta cont ine c^ ampurile @Autowired :
{sessionModel , de tip SessionModel
{searchModel , de tip SearchModel
{resultsModel , de tip ResultsModel
64

{paginationModel , de tip PaginationModel
{documentRetrievalService , de tip DocumentRetrievalServiceIF
Metoda getSearchResults() execut a prin intermediul service-ului
documentRetrievalService c autarea documentelor ^ n funct ie de indexul curent  si
num arul de documente ce se doresc a  a sate pe pagin a, cele dou a criterii din urm a
ind reg asite ^ n paginationModel . Dup a search, este disponibil a o list a de
ResultsWrapper <DocEntity >, put^ and  setate ^ n paginationModel num arul
total de rezultate, accesate prin intermediul metodei getTotalResults() , specic a
clasei generice WrapperResults <T>. Sunt setate, de asemenea, documentele ^ n
cadrul resultsModel , preluate cu ajutorul funct iei getResults() , specic a
aceleia si clase generice. Controller-ul cont ine  si metodele next() ,prev() sau
refreshResults() , care returneaz a lista de rezultate ^ n funct ie de indexul paginii
curente.
Clasa com.rodocea.docshelf.controller.LibraryController
^In cadrul acestei clase se reg asesc obiectele @Autowired :
{resultsModel , de tip ResultsModel
{paginationModel , de tip PaginationModel
{sessionModel , de tip SessionModel
{documentRetrievalService , de tip DocumentRetrievalServiceIF
Metoda de baz a a clasei e getDocumentsInLibrary() . Aceasta foloset e id-ul
user-ului autenticat, indexul curent  si num arul de itemi de a sat pentru a ^ i folosi
drept parametri pentru apelarea metodei getDocumentsInLibrary() , din cadrul
documentRetrievalService . Aceasta returneaz a un obiect de tip
65

ResultsWrapper <DocEntity >, pe baza c aruia se a
 a num arul total de documente
ce se a
 a ^ n libr aria utilizatorului curent, precum  si lista documentelor, acestea dou a
set^ andu-se pe modelele corespunz atoare.
Clasa mai cont ine, de asemenea, funct ii utilizate ^ n returnarea listei de rezultate ^ n
funct ie de indexul paginii curente sau ^ n init ializarea cu valori implicite a
paginationModel .
Clasa com.rodocea.docshelf.controller.HomeController
Cont ine un singur c^ amp adnotat @Autowired , denumit searchModel , de tip
SearchModel  si o singur a metod a clearSearch() , apelat a ca listener ^ n cadrul
unui event preRenderView , pentru resetarea valorilor implicite ale c^ ampurilor
cont inute de searchModel . Acest lucru face ca criteriile dup a care s-a realizat un
search s a nu mai e setate ^ n momentul ^ n care clientul dore ste s a acceseze din nou
pagina de start a aplicat iei.
Pachetul com.rodocea.docshelf.controller.rest
Pachetul cuprinde dou a clase reprezent^ and controllere de rest, ceea ce ^ nseamn a c a ^ n
cadrul lor vor  prelucrate request-urile rest, acest lucru realiz^ andu-se prin utilizarea
adnot arii @RestController . O alt a adnotare folosit a asupra ambelor clase este
@RequestMapping . Aceasta congureaz a URL-ul pe care clasa ^ n cauz a a se va
"mapa".
Clasa com.rodocea.docshelf.controller.rest.PdfRestController
^In cazul acestei clase, URL-ul pe care aceasta se va mapa este "/rest/pdf". Cu alte
cuvinte, orice request HTTP ce va avea loc pe localhost:8080/rest/pdf, va  procesat
66

prin intermediul clasei curente. ^In cadrul ei, este cont inut c^ ampul @Autowired
fileService , care comunic a cu Spring pentru a obt ine ^ n mod automat bean-ul de
tipFileServiceIF (declarat ^ n clasa principal a), f ar a a  nevoie de act iuni
suplimentare, cum ar  instant ierea acestuia.
Se observ a c a adnotarea @RequestMapping nu e prezent a doar la nivel de clas a, ci  si
la nivel de metod a, funct ia getPdf() av^ and aceast a proprietate. Adnotarea, ^ n acest
caz, vine cu valoarea /id, ceea ce ^ nseamn a c a, dac a e lansat un request pe URL-ul
init ial, de tipul localhost:8080/rest/pdf/123, aceast a metod a va  chemat a cu
parametrul id, a c arui valoare este 123, acesta ind declarat prin intermediul
@PathVariable , adnotare ce are ca valoare tot id, la fel ca  si @RequestMapping .
@RequestMapping mai declar a  si faptul c a metoda proceseaz a doar request-uri
HTTP de tip GET, iar atributul produces indic a tipul returnat, adic a un document
de tip PDF , ce are ca mime type application/pdf . Este returnat, a sadar, un
ResponseEntity , clas a generic a ce reprezint a ^ n lumea Java un r aspuns HTTP, ce
cont ine un stream de date, care reprezint a cont inutul  sierului PDF ce se va returna. ^In
nal, se creeaz a  si congureaz a un ResponseEntity cu statusul OK (200), c aruia i se
seteaz a header-ul  si body-ul  si care e trimis ^ napoi c atre caller.
Clasa
com.rodocea.docshelf.controller.rest.ThumbnailRestController
E un controller rest asem an ator, diferent a const^ and ^ n faptul c a ^ n acest caz, URL-ul
mapat controller-ului este /rest/thumbnail , de aceast a dat a tipul returnat este
IMAGE PNG, iarResponseEntity nu mai are setat un header . Se asigur a, astfel, c a
date redundante nu se p astreaz a pe server.
67

2.4 Descrierea altor resurse folosite
Resursele utilizate pentru crearea view-urilor, al aturi de comunicarea lor cu clasele de tip
Controller sau Model, se reg asesc ^ n cadrul directorului src/main/resources :
[src/main/resources]
[META-INF]
[resources]
[resources]
[css]
[images]
[sections]
[home]
[library]
[results]
[view]
[template]
[WEB-INF]
home.xhtml
library.xhtml
results.xhtml
view.xhtml
.
^In cele ce urmeaz a se va face o scurt a referire la component a directorului
src/main/resources/META-INF/resources . Acesta are ^ n component  a directorul
resources , cu folderele css, respectiv images .^In cadrul folderului csssunt suprascrise
stilurile CSS implicite oferite de PrimeFaces , prin  sierele common-style.css  si
primefaces.css . Folderul images cuprinde imaginile folosite pentru construct ia interfet ei
aplicat iei (logo-ul).
Urmeaz a directorul sections , care cuprinde c^ ate un folder specic ec arui view al
aplicat iei: home ,library ,results ,view . Fiecare dintre aceste foldere cont in  sierele de tip
xhtml (EXtensible HyperText Markup Language ), corespunz atoare at^ at paginilor ^ n sine, c^ at
 si modalelor pe care acestea le cont in.
68

Directorul templates are ^ n interiorul s au  sabloane comune ale paginilor xhtml :
commonContext.xhtml , commonFooter.xhtml , commonLayout.xhtml ,
commonModals.xhtml , loggedInHeader.xhtml , loggetOutHeader.xhtml ,
respectiv searchableHeader.xhtml .^In cadrul commonLayout.xhtml sunt declarate
 sierele de tip CSS care le vor suprascrie pe cele default puse la dispozit ie de PrimeFaces , iar
tot aici sunt declarate diferite tipuri de header, folosite ^ n diverse scenarii din aplicat ie, ^ n
funct ie de starea de autenticare a clientului.
WEB-INF cont ine  sierul de congurare faces-config.xml specic JSF. Acesta
cuprinde declarat ii folosite pentru integrarea Spring Framework cuJSF  si comunicarea facil a
dintre cele dou a.
Lista 2.8: Structura  sierului faces-cong.xml
1<facesc o n f i g xmlns=" h t t p : // java . sun . com/xml/ns/ javaee "
2 xmlns:xsi=" h t t p : //www. w3 . org /2001/XMLSchema i n s t a n c e "
3 xsi:schemaLocation=" h t t p : // java . sun . com/xml/ns/ javaee
4 h t t p : // java . sun . com/xml/ns/ javaee /web f a c e s c o n f i g 21 . xsd"
5 v e r s i o n=" 2.1 " >
6
7<a p p l i c a t i o n >
8 <elr e s o l v e r >org . springframework . web . j s f . e l . SpringBeanFacesELResolver </ el
r e s o l v e r >
9</ a p p l i c a t i o n >
10
11</ facesc o n f i g >
^In cele din urm a,  sierele home.xhtml ,library.xhtml ,results.xhtml , respectiv
view.xhtml includ  sierele lor corespunz atoare din sect iunea section , pentru construirea
paginilor cu tot cu dialogurile specice.
69

Capitolul 3
Funct ionalitatea aplicat iei
^In momentul ^ n care utilizatorul acceseaz a aplicat ia, prima pagin a care apare este cea de
home , care ofer a posibilit at i de autenticare, ^ nregistrare, dar  si de c autare.
Fig. 3.1: Pagina de home a aplicat iei
70

3.1 C autarea documentelor ca utilizator neautenticat
Biblioteca digital a ofer a facilit at i de c autare a documentelor  si pentru utilizatori care nu au
un cont propriu creat. Pentru aceasta, user-ul e invitat s a introduc a ^ n bara de search
disponibil a pe prima pagin a cuv^ antul sau cuvintele dup a care se realizeaz a c autarea de
documente (acestea trebuie s a aib a o lungime minim a de 3 litere). Mai mult dec^ at at^ at,
utilizatorul are posibilitatea de a personaliza felul ^ n care operat ia de c autare e efectuat a, prin
alegerea criteriilor ^ n funct ie de care s a se realizeze c autarea: nume sau titlu, autor, cont inut
sau ^ n funct ie de termeni ce nu sunt cont inut i ^ n cadrul documentului, dup a cum se poate
observa ^ n gura de mai jos. C autarea e realizat a implicit ^ n funct ie de cele trei eld-uri
selectate (nume sau titlu, autor, cont inut).
Fig. 3.2: C autarea documentelor ca utilizator neautenticat
Dup a ce este ap asat butonul de search, utilizatorul e redirect ionat pe pagina de rezultate,
acolo unde poate reg asi lista documentelor ce se potrivesc cu termenii c autat i. Acestea pot
cont ine, totodat a, informat ii cu privire la autor, data public arii sau subiectul abordat ^ n
71

cadrul documentului.
Tot aici utilizatorul poate opera alte c aut ari, se poate autentica sau ^  si poate crea un
cont nou. De asemenea, are acces la resursa c autat a, put^ and ap asa butonul "Start reading",
pentru a citi cont inutul documentului.
Fig. 3.3: Returnarea documentelor ca utilizator neautenticat
3.2 ^Inregistrare  si autenticare
Formularele pentru ^ nregistrare  si autenticare reprezint a, de fapt, modale, put^ and  accesate
prin intermediul butoanelor din header-ul paginii de start, "Sign Up", respectiv "Log In".
^In cadrul dialogului destinat ^ nregistr arii unui nou utilizator, toate datele necesare cre arii
unui nou cont sunt obligatorii. ^In momentul ^ n care noul posibil utilizator introduce datele  si
72

le trimite c atre server prin butonul "Join now", cererea e primit a de c atre clasa
SignUpController.java , care efectueaz a valid arile:
1. Veric a dac a datele introduse sunt corecte:
Cele trei c^ ampuri, Username, Password, respectiv Retype Password, nu trebuie s a
r am^ an a necompletate
Retype Password trebuie s a coincid a cu parola introdus a prima dat a
2. Veric a dac a un utilizator cu acela si username exist a deja, iar ^ n cazul ^ n care exist a, este
a sat un mesaj corespunz ator.
Fig. 3.4: Dialog pentru ^ nregistrarea unui nou utilizator
Dac a cererea a trecut de validare, se va crea un nou cont, utilizatorul ind redirect ionat
spre modalul pentru autenticare.
73

Fig. 3.5: C autarea documentelor ca utilizator neautenticat
Utilizatorul este nevoit s a introduc a ^ n dialogul de autenticare, prezent ^ n gura anterioar a,
datele de autenticare (Username  si Password). La fel ca  si ^ n cazul ^ nregistr arii, cererea e
transmis a prin intermediul JSF c atre controller, iar dac a utilizatorul nu a introdus datele sau
acestea sunt incorecte, va primi un mesaj de avertizare la ap asarea butonului "Log in". ^In
schimb, dac a se trece cu succes peste validare, autenticarea e realizat a, utilizatorul trimis
c atre aceea si pagin a de home, dar care pune la dispozit ie acum mai multe facilit at i.
3.3 ^Inc arcarea, accesarea  si manipularea  sierelor
Utilizatorul autenticat poate ^ nc arca  siere PDF , pe care s a le reg aseasc a mai apoi ^ n
library -ul personal. Upload-ul de documente se face prin intermediul butonului "UPLOAD",
prezent ^ n header  si la ap asarea c aruia se deschide o fereastr a prin intermediul c areia user-ul
poate alege  siere de pe ma sina proprie. Dup a ce a ales  sierul, acesta ajunge pe server odat a
cu informat iile aferente lui, numele  sierului (a sa cum a fost salvat pe disc  si care poate
74

modicat ^ n acest moment)  si thumbnail-ul s au ind a sate ^ n dialogul de UPLOAD.
Fig. 3.6: ^Inc arcarea unui document
^In acest moment, utilizatorul e poate renunt a la salvarea documentului, ap as^ and butonul
"Cancel", ceea ce duce la golirea de pe server a informat iilor aduse, e apas a butonul "Save",
ce va duce la salvarea documentului, care va  reg asit ^ n libr arie. ^In cazul salv arii, user-ul e
^ n stiint at cu privire la salvarea cu succes a documentului, care dureaz a de obicei c^ ateva
secunde, ^ n funct ie de m arimea acestuia. Fiind ultimul document ^ nc arcat, acesta se va reg asi
pe prima pozit ie ^ n cadrul libr ariei, ce se poate accesa prin ap asarea butonului "LIBRARY"
pozit ionat ^ n header.
Dup a cum poate  observat, aici nu mai sunt disponibile doar numele documentului  si
thumbnail-urile, ci  si informat ii extrase din metadatele acestuia, ^ n cazul de fat  a titlul,
autorul  si data ^ nc arc arii.
75

Fig. 3.7: Accesarea libr ariei proprii
O diferent  a important a fat  a de act iunile disponibile unui utilizator neautenticat e dat a
de faptul c a, odat a logat, user-ul poate citi, desc arca sau edita documentele ^ nc arcate. Pentru
citirea documentelor, e necesar a ap asarea butonului "Start reading", care va redirect iona
utilizatorul spre un alt tab al browser-ului, ^ n care exist a o component a disponibil a pentru
citire. (vezi Fig. 4.8)
Butonul de "Download" ofer a posibilitatea utilizatorului de a desc arca documente din
library, ind util ^ n cazul ^ n care acestea nu mai exist a pe disc.
Pentru editarea informat iilor unui document, e disponibil butonul "Edit", la ap asarea c aruia
se deschide un nou modal, ce ofer a posibilitatea utilizatorului de a modica date referitoare la
numele, titlul, autorul sau subiectul documentului. (vezi Fig. 4.9)
76

Fig. 3.8: Citirea unui document
Fig. 3.9: Dialog pentru editarea unui document
La ap asarea butonului "Save", ^ n urma edit arii documentului, schimb arile vor ajunge pe
server ^ n mod automat.
77

3.4 C autarea documentelor ca utilizator autenticat
Odat a autenticat, biblioteca ofer a utilizatorului o nou a opt iune ^ n ceea ce prive ste procesul
c aut arii, ind ad augat un nou criteriu dup a care se realizeaz a search-ul,  si anume posibilitatea
de a c auta printre documentele proprii. Acest lucru e util ^ n momentul ^ n care libr aria cont ine
un num ar mare de documente, ce nu mai pot  reg asite at^ at de u sor.
De asemenea, documentele reg asite ^ n urma search-ului pot  desc arcate pe ma sina
proprie. Astfel, c aut^ and acela si termen, "java", vor ap area rezultate ^ n dreptul c arora apare
butonul "Download".
Fig. 3.10: Dialog pentru editarea unui document
Dup a c autarea init ial a  si a sarea rezultatelor corespunz atoare, utilizatorul are
posibilitatea de a c auta din nou printre documente, av^ and la dispozit ie bara de search din
cadrul header-ului.
78

Fig. 3.11: Dialog pentru editarea unui document
^In nal, pentru ie sirea din cont, header-ul pune la dispozit ie butonul "LOG OUT", la
ap asarea c aruia utilizatorul e redirect ionat spre pagina de start specic a userilor neautenticat i,
de unde se pot relua toate procesele descrise mai sus.
79

Capitolul 4
Direct ii ulterioare de dezvoltare
^In clipa de fat  a, aplicat ia Doc-shelf este funct ional a  si prezint a elemente ce o pot face o
unealt a util a utilizatorilor, dar ^ n sect iunea curent a se va ^ ncerca surprinderea unor aspecte
care ar putea s a o duc a la un nivel superior.
Extinderea tipurilor de documente suportate
^In prezent, aplicat ia este conceput a doar pentru lucrul cu documente ^ n format PDF , ^ ns a,
pentru a deveni o bibliotec a digital a puternic a, posibilitatea ^ nc arc arii  si salv arii a mai
multor tipuri de documente ( txt,doc,docx,xml,xls,ppt,pptx, etc) este necesar a. Acest
lucru atrage cu sine, ^ ns a, problema integr arii unor componente care s a fac a posibil a  si
vizualizarea cont inutului documentelor ^ n formate diferite de cel PDF , al c arui caz este
deja rezolvat.
^Inc arcarea simultan a a mai multor  siere
Aplicat ia permite deocamdat a doar ^ nc arcarea unui  sier pe act iune. ^In cazul scenariului
^ n care utilizatorul are nevoie s a ^ ncarce mai multe documente deodat a, timpul necesar
efectu arii acestui lucru va  unul nesatisf ac ator, av^ and ^ n vedere mecanismul actual. De
aceea, o versiune urm atoare ar trebui s a includ a o asemenea facilitate.
80

Crearea de categorii
Se poate pune problema cre arii unor categorii care s a cuprind a documente din aceea si
specialitate, introducerea categoriilor revenind ^ n sarcina utilizatorilor. Astfel, se poate
introduce un nou criteriu reprezentat de aceste categorii, pe baza c aruia s a se realizeze
operat ii de c autare. Acest lucru devine util pentru utilizator, deoarece acela si termen se
poate reg asi ^ n c art i care nu au neap arat leg atur a direct a cu termenul ^ n cauz a.
Evident ierea termenilor c autat i ^ n cadrul documentelor
Solr, ^ mpreun a cu facilit at ile Tika, fac posibil a evident ierea termenilor de c autare reg asit i
^ n interiorul documentelor, proces denumit highlighting . Acest proces poate  ^ mbun at at it
 si prin ^ n stiint area utilizatorului cu privire la num arul paginii la care se reg asesc termenii
c autat i.
Monitorizarea documentelor vizitate
O caracteristic a important a ar  monitorizarea documentelor pe care un utilizator
autenticat le-a parcurs (nu neap arat ^ n ^ ntregime), prin care acesta s a poat a vizualiza
num arul de pagini parcuse  si num arul de pagini r amase din num arul total de pagini pe
care le cuprinde un document. Acest lucru ar ^ mbun at at i semnicativ interactivitatea
aplicat iei.
Documente private  si documente publice
Utilizatorului ar trebui s a i se ofere dreptul, ^ n momentul ^ nc arc arii unui document, de a
seta vizibilitatea documentelor pe care le ^ ncarc a, acestea put^ and  e private, e publice.
De asemenea, se poate opta pentru solut ia ^ n care un utilizator poate seta drepturi altor
utilizatori cu privire la accesarea documentelor lui.
Restrict ionarea vizualiz arii documentelor la un anumit num ar de pagini
Aspect ^ nt^ alnit la numeroase biblioteci digitale importante, un alt feature ar putea
81

consta ^ n disponibilitatea part ial a a documentelor fat  a de utilizatorii neautenticat i,
ace stia put^ and avea acces doar la c^ ateva pagini prezente la ^ nceputul documentelor.
Crearea unui prol utilizator
Pentru a face aplicat ia  si mai dinamic a, se pune problema cre arii unui prol de utilizator,
^ n care acesta s a poat a modica sau ad auga date personale  si, ^ n acest fel, interact iunea
dintre utilizatori s a devin a eventual posibil a.
82

Capitolul 5
Concluzii
^Inceputul activit at ii de dezvoltare a bibliotecii digitale Doc-shelf s-a derulat destul de
greu, ^ ntruc^ at ideea urma s a se concretizeze ^ n jurul unor tehnologii noi (unele
necunoscute p^ an a la momentul ^ n care a fost cu adev arat nevoie de anumite
implement ari). Lipsa de familiaritate cu acestea a dus la o oarecare constr^ angere ^ n ceea
ce prive ste timpul de lucru acordat proiectului, ^ ns a, pe de alt a parte, a contribuit la o
mai bun a ^ nt elegere a domeniului  si a solut iilor existente. Mai mult dec^ at at^ at, se poate
emite ideea conform c areia subiectul bibliotecii digitale a fost un fel de pretext potrivit
pentru a putea folosi m anunchiul de framework-uri init ial pl anuite.
Astfel, chiar dac a subiectul unei biblioteci digitale ar p area la o prim a vedere un model
simplist de implementare, iar Doc-shelf nu realizeaz a ^ n acest sens un avans sau o
noutate ^ n ceea ce prive ste capabilit at ile oferite de un asemenea sistem, existent a unor
modele deja consacrate de abordare a problemelor de c autare ( Apache Solr ), precum  si
existent a unor framework-uri adjuvante ^ n procesul de extragere a informat iilor din
cadrul documentelor ( Apache Tika ), au f acut abordarea acestei tematici fezabil a, ^ n
ciuda unor limit ari impuse de timpul consumat doar pentru ^ nt elegerea funct ion arii
83

anumitor tehnologii  si a congur arii acestora.
Toate aceste tehnologii dinainte pl anuite a  utilizate, dar  si cele de care a fost nevoie ^ n
timpul implement arii, f ar a a  ^ n avans cunoscute, s-au ^ mbinat armonios spre a
construi ceea ce ast azi poart a numele de Doc-shelf , o bibliotec a digital a ^ nc a t^ an ar a, dar
de la care se poate porni un nou proces de ^ mbun at at ire, care s a o transforme ^ ntr-o
unealt a mult mai
exibil a, mult mai ecient a, ^ ntruc^ at ^ n clipa curent a, at^ at indexarea,
c^ at  si c autarea de documente, nu ^ mbrac a cea mai ecace form a.
Cu toate acestea, aplicat ia ^ n sine reprezint a o bun a introducere ^ n cadrul problematicii
studiate, aduc^ and cu sine noutatea cu privire la bibliotecile folosite pentru
implementare, astfel c a produsul software realizat poate  considerat o munc a
investigativ a ^ n ceea ce prive ste facilit at ile oferite de platforma Apache Solr , ^ n cazul de
fat  a ind folosit a doar o mic a parte dintre numeroasele facilit at i enumerate ^ n cadrul
capitolului legat de tehnologiile folosite pe care aceasta poate s a le ofere.
Pentru realizarea solut iei software a fost folosit exclusiv limbajul de programare Java,
care s-a consacrat ^ n ultimii ani ca ind un limbaj extrem de puternic  si abil, preferat
^ n mod special ^ n medii enterprise (standardele J2EE) datorit a suportului excelent oferit
pentru lucrul cu baze de date (JDBC, JPA). ^In cadrul produsului software actual, nu a
fost folosit a o baz a de date, ci s-a apelat la indexarea folosind Apache Solr , care joac a  si
rolul unei baze de date, dar f ar a  una ^ n adev aratul sens al cuv^ antului.
84

Capitolul 6
Bibliograe
[Apaa] Apache. Introduction to the Spring Framework .http://docs.spring.io
/spring/docs/current/spring-framework-reference/html/ov
erview.html .
[Apab] Apache. Introduction to the Spring Framework .http://docs.spring.io
/spring/docs/current/spring-framework-reference/html/ov
erview.html .
[Apac] Apache. Spring Boot Reference Guide .http://docs.spring.io/sprin
g-boot/docs/current-SNAPSHOT/reference/htmlsingle/ .
[Apa15] Apache. Building a RESTful Web Service , 2015. https://spring.io/gu
ides/gs/rest-service/ .
[Fou] Apache Software Foundation. Using SolrJ .https://cwiki.apache.org
/confluence/display/solr/Using+SolrJ .
[Fou15a] Apache Software Foundation. Solr Features , 2015. http://lucene.apach
e.org/solr/features.html .
[Fou15b] Apache Solr Foundation. Apache Solr Reference Guide , 2015. https://cwik
i.apache.org/confluence/display/solr/About+This+Guide .
85

[Gho] Ghost4j. High Level API .http://www.ghost4j.org/highlevelapi.
html .
[Gho10] GhostScript. Overview of GhostScript , 2010. http://www.ghostscript.
com/doc/9.19/Readme.htm .
[Gho16] GhostScript. Overview of GhostScript , 2016. http://www.ghostscript.
com/doc/9.19/Readme.htm .
[Gra] Gradle. Building Java Projects with Gradle .https://spring.io/guides
/gs/gradle/ .
[Pri10a] PrimeTek. Why PrimeFaces , 2010. http://www.primefaces.org/whypr
imefaces .
[Pri10b] PrimeTek. Why PrimeFaces , 2010. http://www.primefaces.org/whypr
imefaces .
[Tuta] TutorialsPoint. Java Server Faces (JSF) Tutorial .http://www.tutorial
spoint.com/jsf/ .
[Tutb] TutorialsPoint. TIKA Tutorial .http://www.tutorialspoint.com/tik
a/tika_overview.htm .
[Tut10] TutorialsPoint. JSF 2.0 Tutorial , 2010. http://www.mkyong.com/tutor
ials/jsf-2-0-tutorials/ .
[Tut15] TutorialsPoint. Spring Tutorial , 2015. http://www.tutorialspoint.com
/spring/index.htm .
86