Iako postoje i drugi načini konfiguriranja Springa, XML format je daleko najpopularniji i najprihvaćeniji, te je prava rijetkost susresti nešto drugo. U verziji Springa 2.0 (čija je finalna verzija izdana u listopadu 2006.) su zbog toga uvedena brojna poboljšanja koja bi trebala konfiguriranje aplikacija baziranih na Springu učiniti bržim, jednostavnijim i fleksibilnijim.
Novost - Springove XML Scheme
U dosadašnjim verzijama Springa, XML konfiguracijske datoteke su tipično započinjale sljedećim odsječkom:
Time je definiran DTD (Documet Type Definition) koji, između ostaloga, propisuje način na koji se zapisuju podaci o bean-ovima. Sami zapisi za bean-ove su generički, otvori se <bean> tag, kao atributi mu se definiraju id i naziv klase, a onda se unutar njega, za pojedina polja vrijednosti definiraju kombiniranjem npr. <property>, <ref> i <value> tagova (ili value atributa). Ovo pravilo vrijedi za sve bean-ove, bilo da se radi o Springovim klasama, o klasama koje ste dobili kao dio nekog API-ja ili ste ih sami napisali. Ovakva generičnost je s jedne strane prednost jer je jasno kako mora izgledati Spring konfiguracija bilo koje Java klase, no također je i ograničenje koje često rezultira prilično dugim i teško preglednim konfiguracijskim datotekama.
DTD definicije nisu ukinute u novoj verziji Springa, te su i dalje ispravan način konfiguriranja. Štoviše, Spring 2.0 u svojoj distribuciji uz stari DTD donosi i novi http://www.springframework.org/dtd/spring-beans-2.0.dtd u kojem se nalaze neke konfiguracijske novosti na koje se nećemo posebno osvrtati u ovom članku (npr., nova područja vrijednosti bean-ova - scope).
Kako prelazak na XML Schema konfiguracije ne znači da morate primijeniti Spring 2.0 konfiguracijske novosti (definicije bean-ova i dalje mogu biti identične kao u Spring 1.x, samo se zaglavlje XML konfiguracije mijenja), a ipak se omogućava njihovo korištenje, DTD zaglavlja ćemo vjerojatno viđati sve manje u aplikacijama baziranim na Spring 2.0.
Jedan tipičan odsječak konfiguracijskog koda koji se do sada susretao bi nalikovao na sljedeći ispis:
Ovo, naravno, nije pravi primjer koji bi pokazao sva ograničenja konfiguracije bazirane na DTD-u, no i ovdje je moguće uočiti ograničenja:
Za dohvat JNDI resursa (bean bankDS) se koristi Springova klasa koja se bavi samo time. Sam naziv klase nam je pomalo nerazumljiv i nebitan te bi zapravo bilo bolje kad bi se na neki drugi (jednostavniji) način moglo naznačiti da želimo dohvatiti JNDI resurs.
Različite klase se sastoje od različitih property-ja, a ipak se svi definiraju na identičan način, pomoću kombinacije tagova <property>, <ref>, <value>, <list>...
Potrebno je znati kako se u Java klasama zovu pojedini property-ji koje želimo popuniti, pri čemu je vrlo lagano napraviti pogrešku u pisanju njihovih naziva. Pojedini alati mogu biti od pomoći, no oni nisu raspoloživi za sve razvojne okoline s kojima se možete susresti (npr. Spring IDE koji prilikom pisanja konfiguracije prikazuje nazive članskih varijabli odabrane klase je skup pluginova koji se integriraju samo u Eclipse, pri čemu Eclipse mora biti verzije 3.1 ili noviji)
Da bismo otkrili koje članske varijable su obavezne, a koje opcionalne, morali bismo pregledati javadoc komentare same klase.
Razni razvojni alati su ograničeni u mogućnosti pružanju podrške prilikom pisanja XML konfiguracija zbog manjka informacija o samim bean-ovima
Kako bismo počeli koristiti Spring 2.0 novosti, prvo moramo promijeniti zaglavlje naše konfiguracijske datoteke na način da zamijenimo spomenutu DTD definiciju XML Schemom. Osnovna XML Schema donosi pravila za pisanje uobičajenih bean-ova (npr. za klase koje smo sami napisali):
Naše bean-ove možemo i dalje pisati na način na koji smo to radili do sada, te je ovakvo zaglavlje po značenju ekvivalentno značenju zaglavlja iz ispisa 1. No, ovako možemo uključiti i još poneku XML Schemu koje će nam pomoći kod korištenja Springovih klasa u našoj konfiguraciji. Npr., ako bismo htjeli na novi način dohvaćati JNDI resurse, uključili bismo jee XML Schemu, kao u sljedećem primjeru zaglavlja (podebljanim slovima su označene izmjene u odnosu na ispis 3):
Osim jednostavnosti samog zapisa, razvojni alati mogu automatski provjeriti da li je naš zapis za navedeni bean ispravan prema jee XML Schemi. Sama jee XML Schema definira da takvi bean-ovi obavezno moraju imati navedenu vrijednost za atribut jndi-name, pa će nam već pri pisanju konfiguracije od strane razvojnog alata biti naznačeno da smo napravili grešku ako smo ga izostavili. Osim toga, razvojni alati će često ponuditi sve moguće atribute, kao i vrijednosti koje im je moguće dodijeliti.
Osim JNDI resursa, novi način konfiguriranja će olakšati definiranje AOP bean-ova ili npr. transakcijskog konteksta. Ne ulazeći u detalje (uočite npr. nedostatak definicije bean-a txManager koji ovisi o resursima nad kojima definiramo transakciju), ako bismo htjeli postaviti transakcijski timeout na neki naš servis, napisali bismo sljedeći odsječak konfiguracije :
Predefinirani namespace-i
Spring 2.0 donosi 6 predefiniranih namespace-a raspoloživih za korištenje, uz obećanje da će novije verzije Springa postupno dodavati nove kako bi se olakšalo konfiguriranje u verziji 2.0 zapostavljenih područja (npr. Spring MVC klasa):
tx – olakšava definiranje transakcija
aop – pojednostavljuje AOP konfiguracije
jee – donosi podršku za definiranje JNDI resursa, EJB-ova i slično
lang – za rad s objektima definiranim u dinamičkim jezicima, poput Groovy ili JRuby
util – za svakodnevne zadatke, najviše vezano za učitavanje java.util.Properties objekata
<tx:advice id="txAdvice" transaction-manager="txManager">
<tx:attributes>
<!— set timeout to 120 seconds on all methods -->
<tx:method name="*" timeout="120"/>
</tx:attributes>
</tx:advice>
<aop:config>
<aop:pointcut id="allMethods" expression="execution(*
net.croz.fyi.spring.BankService.*(..))"/>
<aop:advisor advice-ref="txAdvice" pointcut-ref="allMethods"/>
</aop:config>
Namespace p
Definiranje vlastite XML Scheme nije potpuno jednostavno te iziskuje određeni napor. Također, za brojne već postojeće biblioteke klasa XML Schema dokumenti još ne postoje. Srećom, Spring 2.0 donosi poseban namespace koji možemo upotrijebiti na bilo kojem bean-u. Na taj način dobijamo pojednostavljenje konfiguracije i za situacije kad XML Schema ne postoji.
Namespace p omogućava definiranje vrijednosti property-ja klase kroz atribute taga <bean>, bez potrebe za kombiniranje brojnih XML elemenata koje smo do sada morali koristiti. Npr. neki property naziva color kojem bismo željeli pridijeliti vrijednost green bi se definirao atributom p:color="green".
Vlastite XML Scheme
Kako ćete razvijati svoje biblioteke klasa, možda ćete poželjeti na sličan način dodati podršku za svoje bean-ove. Spring vam to omogućuje, a sam zadatak se sastoji od 3 koraka:
Definiranje svojeg XML Schema dokumenta koji opisuje vaše bean-ove
Implementiranje sučelja NamespaceHandler iz paketa org.springframework.beans.factory.xml kojim definirate način generiranja objekata na temelju vaše scheme
Mijenjanje datoteke spring.handlers na način da registrirate vašu NamespaceHandler klasu. Na taj način biste Spring „naučili“ kako mora obrađivati bean-ove koji su definirani preko vaše scheme
Možda se pitate kako bi se onda definirao property koji pokazuje na objekt? Jednostavno, na naziv property-ja biste dodali sufiks -ref, a vrijednost koju mu pridijelite predstavlja id bean-a u Spring konfiguraciji.
Kako se namespace p ne provjerava, morat ćete biti oprezni prilikom pisanja naziva atributa, a niti razvojni alati vam za sada neće biti od velike pomoći, no osnovna namjena ovog namespace-a je ionako samo pojednostavljenje konfiguracije.
Sad bismo mogli pogledati kako bi u konačnici korištenjem Spring 2.0 konfiguracijskih novosti izgledala potpuna konfiguracijska datoteka s početka članka (ispisi 1 i 2). Podebljanim slovima je označen dio kojim smo uključili namespace p u našu konfiguraciju: