Wielokrotnie wchodząc na przeróżne strony zamiast oczekiwanej przeze mnie treści pojawiała się strona z błędami aplikacji, i nie był to tylko komunikat w stylu „Błąd strony” a pełne kody błędów, łącznie ze stacktracem czy też kodem strony (jeśli była pisana w języku skryptowym). Nie trzeba chyba nikomu tłumaczyć, że tego typu treść nigdy nie powinna być widoczna dla użytkownika końcowego. I nie tylko dlatego, że strona taka brzydko wygląda i może odstraszyć użytkowników. Treści wyjątków jakie powoduje aplikacja, czy też część kodu jakie pojawią się mogą być bez problemu wykorzystane przez osoby interesujące się zabezpieczeniami.

W bibliotece SpringFramework, istnieje coś takiego jak ExceptionHandler, który działa lokalnie i jest implementowany per kontroler co przy większej aplikacji może być mało wygodne. Niestety globalny mechanizm przechwytywania powstanie najwcześniej w wersji 3.2(kiedyś przeczytałem pewien komentarz programisty Springa w ich systemie Jira) więc puki co musimy radzić sobie sami. Prosty system przechwytujący wyjątki można napisać samemu i nawet specjalnie się przy tym nie napracujemy.
Do stworzenia takiego systemu będziemy potrzebować najnowszych bibliotek Springa oraz bibliotek wspomagających programowanie aspektowe (aspectjweaver)

Na początek skonfigurujemy klasę która będzie obsługiwać wyjątki, konfigurację umieszczamy w applicationContext.xml

</pre>
<aop:aspectj-autoproxy />
 <aop:config>
 <aop:aspect id="exceptionHandler" ref="globalExceptionHandler">
 <!-- find all methods that returns ModelAndView objects -->
 <aop:pointcut expression="execution(org.springframework.web.servlet.ModelAndView+ *(..))" id="returningMav" />
 <!-- and execute them inside exceptionHandler -->
 <aop:around method="exceptionHandler" pointcut-ref="returningMav" />
 </aop:aspect>
 </aop:config>
 <bean id="globalExceptionHandler" class="com.darekzon.spring.exhandler.aop.ExceptionHandler" />
<pre>

Powyższy zapis konfiguruje system tak aby wyłapał wszystkie metody zwracające obiekt „ModelAndView” (czyli zazwyczaj metody mapujące URL-e) i przekazywał je do naszego obiektu, a dokładniej do metody „exceptionHandler” w klasie „ExceptionHandler”.
Metody te będą przekazywane w formie obiektu ProceedingJoinPoint posiadającego metodę „proceed” która służy do wywołania domyślnej akcji.

Nasza metoda obsługująca wyjątki wygląda jak poniżej

public ModelAndViewexceptionHandler(ProceedingJoinPoint pjp)throws Throwable{
        ModelAndView mav=newModelAndView();
        try{
            mav=(ModelAndView) pjp.proceed();
        }catch(Exceptionae){
            mav.addObject("exceptionMessage",ae.getMessage());
            mav.setViewName("exception");
        }
        return mav;
    }

Działanie jest proste, wywołaj metodę która może rzucić wyjątek (tj. metodę obsługującą url) i jeśli taki wyjątek zostanie rzucony, złap go, dodaj jego wiadomość do widoku jako ‘exceptionMessage’ oraz wygeneruj widok o nazwie ‘exception’. A co za tym idzie, jeśli nasza metoda kontrolera wyrzuci wyjątek, zostanie on złapany a zamiast niego zostanie zwrócony poprawny obiekt ModelAndView.

Oczywiście zamiast prostej podmiany widoków możemy przekierować użytkownika do innej strony, zapisać logi, czy też wysłać maila.

Działający projekt

Działający projekt można pobrać przeglądać pod adresem https://github.com/darek/spring.3.examples/tree/master/aop-global-exception-handler

Jak dowiedziałem się przed chwilą, Atlassian wypuścił nową wersję swojego serwisu Bitbucket który służył jako hosting dla naszych projektów. Jeszcze do niedawna Bitbucket obsługiwał jedynie Mercurial jednak to się zmieniło. Wraz z nową wersją serwisu doszła obsługa Git-a co bardzo mnie cieszy. Prócz wsparcia dla Git-a mamy możliwość zintegrowania z wieloma serwisamy (Jenkins – dawny Hudson, Jira, Twitter itd.)

Jak dla mnie to duży krok, do tej pory w moim przekonaniu nie istniał żaden serwis (godny zaufania) udostępniający darmowe prywatne repozytoria dla Git-a (co prawda Beanstalkapp ma darmowe konta nazwane Trial ale są mocno ograniczone) na taką skalę. Z dużym prawdopodobieństwem bitbucket wprowadzi odrobinę zamieszania.

Nie tak dawno temu przedstawiałem nowy serwis udostępniający chmurę obliczeniową od CloudBees a już na horyzoncie pojawia się nowy zawodnik. Tym razem mamy do czynienia z produktem Cloud Foundry firmy VMware.
Cloud Foundry umożliwia uruchomienie aplikacji stworzonych z wykorzystaniem takich frameworków jak Spring, Rails, Node.js, Grails oraz Sinatra. 

Usługa Cloud Foundry podzielona jest na 3 części:

• CloudFoundry.com  - kompletne komercyjne środowisko  udostępnione na zasadzie PaaS
• CloudFoundry.org – otwarty projekt w którym każdy może poprawić kod aplikacji CloudFoundry (kod źródłowy dostepny pod adresem: https://github.com/cloudfoundry )
• CloudFoundry Micro Cloud – virtualna maszyna z prywatnym CloudFoundry do uruchomienia na własnych komputerze

Na dzień dzisiejszy serwis jest w fazie testów i żeby wypróbować jego możliwości trzeba zapisać się i czekać na zaproszenie (ja czekałem 2 tygodnie).

Dodatkowe informacje na temat projektu znajdziecie na kanale Youtube.

Oracle przy współpracy z Intel-em organizuje 27 stycznia spotkanie na temat przetwarzania w chmurze. Każdy uczestnik będzie mógł dowiedzieć się jak zbudować nowoczesną architekturę przetwarzania w chmurze, zobaczyć przykładowe wdrożenia, czy też poznać najlepsze najlepsze procedury sprawdzone w sytuacjach rzeczywistych. Spotkanie odbywa się w hotelu Raddison BLU przy ulicy Grzybowskiej 24 w Warszawie.

Więcej informacji oraz możliwość zarejestrowania się (liczba miejsc ograniczona) dostępne na stronie spotkania

Jak zapowiedziałem w poprzednim poście tym razem pobawimy się Sitemesh-em i atrybutami kontekstowymi w JSP, więc będzie to wpis raczej krótki. Skupimy się na rozdzieleniu szablonów (layoutu) aplikacji na 2 części. Pierwszy szblon zastosujemy do panelu administracyjnego, wyświetlać będzie listy, formularze i dane, a także umieści na każdej stronie menu administracyjne. Drugi szablon będzie wykorzystywany jedynie podczas logowania i prócz formularza  nie będzie zawierał nic więcej. Oczywiście jeśli ktoś chce może śmiało dodać więcej szablonów, np. specjalna strona dla obsługi zamówień która zawiera oddzielne menu, czy też

W pierwszej części tutorialu wspomniałem iż Sitemesh służy do składania stron w całość, dzięki niemu możemy stworzyć szablon strony, do którego będziemy doklejać wyniki stron co skutecznie  ułatwia tworzenie widoków. Co prawda biblioteka ta potrafi więcej (w wersji 2.x) ale z racji, że korzystamy z wersji alpha lepiej używać jedynie podstawowych funkcjonalności (przynajmniej w tej chwili).

Rozdzielamy szablony

Sitemesh-a skonfigurowaliśmy w pierwszej części tuorialu, miał on za zadanie składać główny szablon (default.jsp) z widokami wyników wygenerowanymi przez aplikację, teraz zajmiemy się rozdzieleniem szablonów dla widoku logowania oraz dla pozostałej części aplikacji. Jak wiadomo, konfigurację Sitemesh-a trzymamy w klasie com.darekzon.bookstore.filter.Sitemesh, i aktualnie zawiera wpis mówiący, że każdy wyniki ma być „wklejony” do szablony default.jsp. Aby utworzyć dodatkowy szablon wystarczy dopisać regułę która dla żądania /login.html będzie stosować inny szablon. Całość wygląda następująco:

package com.darekzon.bookstore.filter;
import org.sitemesh.builder.SiteMeshFilterBuilder;
import org.sitemesh.config.ConfigurableSiteMeshFilter;
public class Sitemesh extends ConfigurableSiteMeshFilter {
  protected void applyCustomConfiguration(SiteMeshFilterBuilder builder) {
    builder.addDecoratorPath("/login.html", "/views/layout/login.jsp");
    builder.addDecoratorPath("/*", "/views/layout/default.jsp");
  }
}

W powyższym zapisie ważna jest kolejność wpisów (odwrotny zapis przysłaniałby nam szablon login.jsp dla wywołania strony logowania.

Teraz wystarczy stworzyć odpowiedni plik (np. bazując na wcześniejszym szablonie) i gotowe, zapytanie o stronę /login.html otrzyma własną stronę wynikową.

Tworzymy menu administracyjne

Teraz zajmiemy się tworzeniem menu, czynność z pozoru prosta, wystarczy wpisać kilka tagów i gotowe, jak jednak sprawić by nasze menu rozpoznawało gdzie aktualnie się znajdujemy i na bazie tego zaznaczało w menu naszą pozycję? W poprzednim projekcie używałem Sitemesh 2.x który w łatwy sposób odczytywał metatagi stron dzięki czemu łatwo można było określić naszą pozycję, niestety w wersji 3 nie działa to jak trzeba, a na pewno nie jest to w żaden sposób udokumentowane, więc trzeba sobie poradzić w inny sposób. Rozwiązaniem jakie wymyśliłem, jest ustawianie atrybutów strony w zależności od tego gdzie jesteśmy. Jak to działa?

Jak wszyscy wiemy, każda akcja posiada własny plik za pomącą którego generowany jest widok, w każdym z tych plików wstawiamy zapis:

<% pageContext.setAttribute("moduleName","content", PageContext.REQUEST_SCOPE); pageContext.setAttribute("pageName","index", PageContext.REQUEST_SCOPE); %>

Powyższy kod, ustawił nam w pliku widoku 2 atrybuty, moduleName która oznaczać będzie w jakiej grupie znajduje się strona oraz pageName która oznacza jaka strona jest generowana, PageContext.REQUEST_SCOPE mówi aplikacji, że atrybuty będą widoczne tylko w zakresie aktualnego żądania (więcej nam nie trzeba).

Zabieramy się za tworzenie menu, ponieważ menu. Możemy je stworzyć w pliku szablonu albo w oddzielnym pliku który dołączymy do naszego szablonu, ponieważ nie lubię chaosu, wybieram rozwiązanie drugie.
Tworzymy plik navigation.jsp (w folderze includes) oraz dołączamy go do naszego szablonu default.jsp dyrektywą:

<%@ include file="../includes/navigation.jsp" %>

Dołączony plik ma za zadanie odczytać atrybuty ustawione w widokach (patrz wyżej) oraz oznaczenie grupy i podstron klasą active gdy są one aktywne, dzięki czemu będziemy mogli za pomącą CSS-a odpowiednio pokazywać i ukrywać nasze menu. Nasze menu zbudowane będzie z zagnieżdżonych list nieuporządkowanych według struktury:

<ul>
	<li>GRUPA
<ul>
	<li>PODSTRONA</li>
</ul>
</li>
</ul>

Plik ten prezentuje się następująco:

<%@ taglib prefix="tag" uri="http://www.springframework.org/tags" %>
<% String moduleName = (String) pageContext.getAttribute("moduleName",PageContext.REQUEST_SCOPE);  String pageName = (String) pageContext.getAttribute("pageName",PageContext.REQUEST_SCOPE); %>
<ul>
	<li class="<% if(moduleName==">">
      <a href="<%= request.getContextPath() %>/content.html">

      </a></li>
	<li class="<% if(moduleName==">">
      <a href="<%= request.getContextPath() %>/catalog.html">

      </a>
<ul>
	<li class="<% if(moduleName==">">
          <a href="<%= request.getContextPath() %>/catalog/categories.html">

          </a></li>
	<li>
          <a href="<%= request.getContextPath() %>/catalog/books.html">

          </a></li>
</ul>
</li>
	<li class="<% if(moduleName==">">
      <a href="<%= request.getContextPath() %>/orders.html">

      </a></li>
	<li class="<% if(moduleName==">">
      <a href="<%= request.getContextPath() %>/clients.html">

      </a></li>
	<li>
      <a href="<%= request.getContextPath() %>/settings.html">

      </a>
<ul>
	<li>
          <a href="<%= request.getContextPath() %>/settings/administrators.html">

          </a></li>
</ul>
</li>
	<li class="logout">
      <a href="<%= request.getContextPath() %>/wyloguj.html">

      </a></li>
</ul>

Plik dołącza bibliotekę tagów wykorzystywaną do obsługi wiadomości, oraz odczytuje wcześniej ustawione atrybuty zapisując je do zmiennych. W kolejnych pozycjach menu następuje sprawdzenie aktualnej pozycji.
Gdy moduleName jest równe wymaganej wartości zostaje ustawiona klasa active, to samo tyczy się zmiennej pageName. Dzięki takiemu rozwiązaniu mamy nasze „dynamiczne” menu.

Jeśli ktoś zna lepsze rozwiązanie z chęcią je poznam.

PS. Jeśli chodzi o zapis request.getContextPath() to zwraca nam on ścieżkę wywołania aplikacji, tzn. jeśli nasza aplikacja działała by w folderze bookstore a jej uruchomienie wiązałoby się z wpisanie adresu http://example.com/bookstore/ to getContextPath() zwróci nam ciąg /bookstore, dzięki czemu wszystkie linki będą poprawnie obsłużone bez względu na to, czy nasza aplikacja jest uruchomiona na własnej domenie, czy też działa „w folderze”.

Jak pobrać projekt

Projekt został umieszczony na serwerach GitHub.com. Adres bezpośredni do projektu: https://github.com/darek/bookstore.
Dodatkowo zostało uruchomione repozytorium GIT dla wszystkich chętnych i dostępny jest pod adresem: git://github.com/darek/bookstore.git

W drugiej części tutorialu udało nam się stworzyć mechanizm dodawania administratorów do naszego panelu, byłoby nierozsądne by każdy użytkownik miał do niego dostęp, dlatego w tej części zajmiemy się mechanizmem kontroli dostępu do naszej aplikacji. Wpis obejmie konfigurację mechanizmów uwierzytelniania oraz autoryzacji wykorzystujących Spring Security (w tym hasła użytkowników zakodowane algorytmem sha256 + z wykorzystaniem tzw. soli). Miało być też coś o Sitemeshu, ale zrobię to w następnym odcinku który pojawi się na dniach.

Zabezpieczanie aplikacji

Konfiguracja zabezpieczeń obejmuje dwa pliki, web-security.xml oraz web.xml. Pierwszy z nich zawiera już konfigurację obiektu szyfrującego hasła oraz mechanizm soli (z wcześniejszego tutorialu), tym razem musimy dodać obsługę poziomów dostępu oraz mechanizmu uwierzytelniania opartego o bazę danych. Konfiguracja taka prócz skonfigurowanych już wcześniej obiektów zawierać powinna manager uwierzytelniania, dostawcę danych uwierzytelnianych, filtr przechwytujący, oraz listę reguł które będą mówić mechanizmowi, kto gdzie ma dostęp i ew. gdzie ma się zalogować. Zmiany w tym pliku wyglądają następująco

(pełna zawartość pliku w repozytorium – zobacz koniec wpisu):

<authentication-manager alias="authenticationManager">
<authentication-provider ref="authProvider" />
</authentication-manager>

<beans:bean id="authProvider"
class="org.springframework.security.authentication.dao.DaoAuthenticationProvider">
<beans:property name="userDetailsService" ref="userService" />
<beans:property name="passwordEncoder" ref="passwordEncoder" />
<beans:property name="saltSource" ref="saltSource" />
<beans:property name="includeDetailsObject" value="true" />
</beans:bean>

<beans:bean id="authenticationProcessingFilterEntryPoint"
class="org.springframework.security.web.authentication.AuthenticationProcessingFilterEntryPoint">
<beans:property name="forceHttps" value="false" />
<beans:property name="loginFormUrl" value="/login.html" />
</beans:bean>

<http entry-point-ref="authenticationProcessingFilterEntryPoint" auto-config="true">
<!-- <intercept-url pattern="/**" access="ROLE_ADMIN" /> -->
<intercept-url pattern="/login.html" filters="none" />
<logout logout-url="/logout.html" />
<anonymous granted-authority="ROLE_ANONYMOUS" />
<form-login login-page="/login.html" login-processing-url="/j_spring_security_check.html"
authentication-failure-url="/login.html?error=true" />
</http>

Czyli:

authentication-manager: mechanizm odpowiedzialny za uwierzytelnianie, przekazujemy mu referencje do obiektu odpowiedzialnego za dostarczenie informacji o użytkownikach

authProvider: obiekt odpowiedzialny jest za dostarczenie użytkowników (tj, pobranie użytkownika na podstawie loginu), w naszym wypadku obiekt korzysta z bazy danych oraz dodatkowych obiektów szyfrujących. authProvider posiada również parametr userDetailsService który powinien wskazywać na obiekt odpowiedzialny za wyszukanie użytkownika, obiekt taki wskazujemy poprzez nadanie mu id userService (patrz web-data.xml).

authenticationProcessingFilterEntryPoint: obiekt rozpoczynający proces autoryzacji, przechowuje ścieżkę (w formie URL-a) do strony z formularzem logowania

http: najważniejsza część, tutaj ustawiamy poziomy dostępów do konkretnych zasobów, ustalamy również formularza logowania oraz adres powodujący wylogowanie. (UWAGA! jeśli ustalamy niestandardowy adres logowania należy wyłączyć mu poziom dostepu (filter=”none”) inaczej dostaniemy pętle przekierowań)

Według powyższej konfiguracji nasza aplikacja jest dostępna tylko dla użytkowników z poziomem dostępu ROLE_ADMIN, jeśli nie jesteś zalogowany zostajesz automatycznie przekierowany na stronę /login.html która wyświetla formularz i wysyła go pod adres /j_spring_security_check.html, jeśli logowanie się nie powiedzie, do adresu logowania zostanie dopisany parametr error=true, gdy natomiast podasz poprawne dane logujące zostaniesz przeniesiony na wcześniej żądaną stronę, lub na stronę główną serwisu. Aby się wylogować musisz wejść pod adres /logout.html.

W pliku web.xml ustawiamy filtr który każde żądanie kończące się rozszerzeniem .html będzie „testował” pod względem bezpieczeństwa (tzn. czy użytkownik wywołujący żądanie ma prawo je wykonać), zdefiniowany filtr wygląda tak (pełna zawartość pliku w repozytorium – zobacz koniec wpisu):

<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>*.html</url-pattern>
</filter-mapping>

Jak wspomniałem wcześniej gdy użytkownik nie ma praw do wykonania danego żądania, bądź nie jest zalogowany zostaje automatycznie przekierowany do strony loguj.html. Ponieważ nie jest to standardowa strona musimy sami obsłużyć to żądanie, na szczęście nie jest to trudne, wymaga tylko 2 elementów, metody w kontrolerze która obsłuży żądanie oraz widoku formularza który wyświetli pola do podania loginu i hasła. Akcja w kontrolerze dodatkowo przyjmie parametr error (o czym mówiłem wcześniej) który posłuży do wykrycia czy akcja logowania się nie powiodła i jeśli jest to prawdą wyświetli odpowiedni komunikat.

Metodę obsługującą logowanie zawarłem w kontrolerze IndexController i wygląda ona następująco (pełna zawartość pliku w repozytorium – zobacz koniec wpisu):

@RequestMapping(value = "/login", method = RequestMethod.GET)
 public ModelAndView login(@RequestParam(value = "error", required = false, defaultValue = "false") boolean error) {
 ModelAndView mav = new ModelAndView("index/login");
 mav.addObject("isError", error);
 return mav;
 }

@RequestParam pobiera parametr przekazywany w żądaniu i przekazuje go w zmiennej error, parametr ten nie jest wymagany, więc jeśli nie istnieje do zmiennej error zostanie przypisana wartość domyślna false. Parametr error przekazywany jest do widoku który prezentuje się następująco:

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core_rt" %>
<%@ taglib prefix="tag" uri="http://www.springframework.org/tags" %>
<div></div>
<div>
<form action="<c:url value=">
" method="POST">
<div>
 <label for="login"></label>
 <input id="login" name="j_username" /></div>
<div>
 <label for="password"></label>
 <input id="password" name="j_password" type="password" /></div>
<div>
 <input type="submit" /></div>
</form></div>

Jak widzimy powyżej, najpierw sprawdzamy czy zmienna isError jest równa true co by oznaczało, że podaliśmy błędne dane podczas logowania, jeśli warunek jest spełnony zostaje wyświetlony komunikat. Następnie tworzymy formularz który metodą POST przesyła dane pod adres /j_spring_security_check.html który jak pamiętacie ustawiliśmy wcześniej w pliku web-security.xml. Formularz musi zawierać przynajmniej dwa pola (login i hasło) które dodatkowo powinny przyjmować odpowiednie nazwy: j_username dla nazwy użytkownika oraz j_password dla jego hasła.

Byłoby wspaniale gdyby na tym zakończyła się konfiguracja, niestety musimy zmodyfikować klasę encji Account by mogła być poprawnie przetwarzana przez Spring Security. Aby nasza klasa była poprawnie obsługiwana musi rozszerzać klasę User (z pakietu org.springframework.security.core.userdetails) oraz implementować interfejs UserDetails (z tego samego pakietu).
W naszym wypadku implementacja wygląda następująco (pełna zawartość pliku w repozytorium – zobacz koniec wpisu):

public class Account extends User implements UserDetails {

@Override
 public Collection getAuthorities() {
 Set ga = new HashSet();
 for (AccountRole ar : this.accountRole) {
 ga.add(new GrantedAuthorityImpl(ar.getRole()));
 }
 return ga;
 }
<pre> @Override
 public boolean isEnabled() {
 if (this.accountRole.size() > 0) {
 return true;
 }
 return false;
 }</pre>
@Override
 public boolean isAccountNonExpired() {
 return this.isEnabled();
 }

 @Override
 public boolean isAccountNonLocked() {
 return this.isEnabled();
 }

 @Override
 public boolean isCredentialsNonExpired() {
 return this.isEnabled();
 }

}

Zostały zaimplementowane metody:

public Collection<GrantedAuthority> getAuthorities() – zwraca listę poziomów dostępu jakie posiada użytkownik, czyli nasze AccountRole,
public boolean isEnabled() – zwraca true jeśli konto jest aktywne, w naszym wypadku kierujemy się zasadą „Jeśli użytkownik ma przypisaną rolę to konto jest aktywne”,
public boolean isAccountNonExpired() – zwraca true jeśli konto nie wygasło,
public boolean isAccountNonLocked() – zwraca true jeśli konto nie jest zablokowane,
public boolean isCredentialsNonExpired() – zwraca true jeśli poziomy dostępów nie wygasły

Musimy również dodać metodę loadUserByUsername która będzie wykorzystywana przez dostawcę autoryzacji do znalezienia użytkownika. Funkcja ta wykorzystuje metodę findUsername z klasy AccountDao którą wykorzystujemy podczas rejestracji, i prezentuje się ona następująco (pełna zawartość pliku w repozytorium – zobacz koniec wpisu):

@Override
 public UserDetails loadUserByUsername(String username)
 throws UsernameNotFoundException, DataAccessException {
 try {
 return (UserDetails) accountDao.findUsername(username);
 } catch (UserNotFoundException e) {
 throw new UsernameNotFoundException(username);
 }
 }

Metodę tą dodajemy do obiektu który jest wskazany w obiekcie authProvider jako parametr userDetailsService, w naszym wypadku było to dodanie identyfikatora userService do obiektu AccountServiceImpl w pliku web-data.xml (pełna zawartość pliku w repozytorium – zobacz koniec wpisu):

<bean id="userService" class="com.darekzon.bookstore.service.AccountServiceImpl" />

I to wszystko, tak skonfigurowany mechanizm powinien działać poprawnie, pamiętajcie tylko, żeby włączyć zabezpieczenia po dodaniu użytkownika.

Jak pobrać projekt

Projekt został umieszczony na serwerach GitHub.com. Adres bezpośredni do projektu: https://github.com/darek/bookstore.
Dodatkowo zostało uruchomione repozytorium GIT dla wszystkich chętnych i dostępny jest pod adresem: git://github.com/darek/bookstore.git

W tej części tutorialu skupimy się na skonfigurowaniu połączenia z bazą danych, podłączeniu frameworka hibernate do naszej aplikacji oraz zobaczymy jak tworzyć encje i jak sprawdzać poprawność danych przed ich zapisem (walidacja).

Przygotowanie do pracy

W poprzedniej części przygotowaliśmy w ramach części klienckiej małą aplikację „witaj świecie”, ponieważ projekt nie zawierał elementów stricte przyporządkowanych części dla klienta możemy skopiować go (głównie pliki konfiguracyjne) i użyć w panelu administracyjnym (prawie jak copypasteryzm).

Aby przejść przez tą część tutoriala będziemy musieli zainstalować bazę danych PostgreSQL oraz pobrać kilka dodatkowy bibliotek (zrobimy to wykorzystując mavena).
Jak wspomniałem w pierwszym odcinku tutoriala, wspólne klasy będą trzymane w osobnym projekcie „bookstore-lib”, tam przechowywane będą klasy Encji, Dao oraz Serwisy, a także wspólne klasy które będą wykonywać specyficzne zadania (powstaną wkrótce), eclipse zadba, by dołączyć je automatycznie podczas kompilacji. Projekt „bookstore-lib” również korzysta z mavena do obsługi bibliotek wykorzystanych w projekcie, nie posiada on natomiast zintegrowanego Spring frameworka (co jest logiczne). Nad jego konfiguracją rozpisywać się nie będę, stworzyłem czysty projekt, dodałem obsługę mavena i zacząłem pisać klasy (w tym przypadku na pierwszy ogień poszły Encje), gdy eclipse wykrył, że nie mam jakiejś klasy zależnej dodałem ją do projektu ustawiając odpowiedni zakres (scope – jeśli klasa wykorzystywana jest w panelu, zakres ustawiałem na runtime, jeśli była używana stricte w bookstore-lib, zakres ustawiany był na compile).

Projekt „bookstore-admin” prócz bibliotek potrzebnych do uruchomienia Springframework-a potrzebuje również bibliotek odpowiedzialnych za obsługę bazy danych oraz walidację formularzy, do pliku pom.xml dodałem następujące biblioteki (tu również skorzystałem z zakresów – scope, dzięki czemu aplikacje nie posiadały zdublowanych bibliotek).

<dependency>
 <groupId>postgresql</groupId>
 <artifactId>postgresql</artifactId>
 <version>8.4-701.jdbc4</version>
 <type>jar</type>
 <scope>compile</scope>
 </dependency>
 <dependency>
 <groupId>org.springframework</groupId>
 <artifactId>spring-orm</artifactId>
 <version>3.0.2.RELEASE</version>
 <type>jar</type>
 <scope>compile</scope>
 </dependency>
 <dependency>
 <groupId>org.hibernate</groupId>
 <artifactId>hibernate-core</artifactId>
 <version>3.3.2.GA</version>
 <type>jar</type>
 <scope>compile</scope>
 </dependency>
 <dependency>
 <groupId>org.hibernate</groupId>
 <artifactId>hibernate-entitymanager</artifactId>
 <version>3.4.0.GA</version>
 <type>jar</type>
 <scope>compile</scope>
 </dependency>
 <dependency>
 <groupId>org.slf4j</groupId>
 <artifactId>slf4j-log4j12</artifactId>
 <version>1.5.8</version>
 <type>jar</type>
 <scope>compile</scope>
 </dependency>
<dependency>
 <groupId>org.hibernate</groupId>
 <artifactId>hibernate-validator</artifactId>
 <version>4.0.2.GA</version>
 </dependency>

Konfiguracja bazy danych

Konfiguracja bazy danych jak i wszystkich elementów związanych z obsługą zapisu do bazy danych oraz odczytu z niej znajduje się w pliku web-data.xml (trzeba być porządnym programistą i nie tworzyć śmietnika konfiguracyjnego).
Zanim skonfigurujemy połączenie z bazą danych musimy stworzyć użytkownika bazy danych oraz dodać bazę z którą będzie się łączyć, jeśli ktoś nie wie polecam google.com lub program pgAdmin. Połączenie z bazą danych możemy skonfigurować na 2 sposoby (tyle znam), pierwszy (standardowy), czyli dostęp do bazy poprzez adres serwera+port oraz dane uwierzytelniające, drugi to dostęp do bazy poprzez nazwę JNDI (czytaj więcej o Java Naming and Directory Interface API), ważną zaletą (moim zdaniem) połączenia JNDI jest niezależność ustawień autoryzacyjnych, ponieważ łączymy się z bazą nie poprzez login i hasło, a ustaloną wcześniej przez serwer nazwę, możliwe jest bezproblemowe (bez potrzeby ponownego grzebania w konfiguracji) zmienianie danych autoryzacyjnych, czy też adresu bazy danych dlatego też oprę naszą aplikację o ten typ połączenia.
Ponieważ połączenia JNDI opierają się na skonfigurowanej nazwie musimy taką konfigurację wprowadzić. W naszym przypadku (tomcat 6.0) robimy to w pliku TOMCAT_HOME/conf/context.xml¹ poprzez wpisanie między tagi <context> zawartości:

<Resource auth="Container" driverClassName="org.postgresql.Driver" name="bookstore" password="bookstore" type="javax.sql.DataSource" url="jdbc:postgresql://localhost:5432/bookstore" username="bookstore"/>

Co w skrócie oznacza „przypisz nazwie bookstore połączenie do bazy o nazwie bookstore znajdującej się pod adresem localhost, na porcie 5432 wykorzystując nazwę użytkownika bookstore oraz hasło bookstore„.

Nasza aplikacja korzystać będzie z frameworka hibernate, dlatego potrzebujemy skonfigurować jego działanie. Konfiguracja taka polega na utworzeniu pliku  hibernate.cfg.xml w  classpath (np. src/META-INF; może ktoś zna polski odpowiednik classpath) i wpisujemy zawartość:

<!DOCTYPE hibernate-configuration PUBLIC
 "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
 "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
 <session-factory>
 <property name="hibernate.dialect">org.hibernate.dialect.PostgreSQLDialect</property>
 <property name="hibernate.hbm2ddl.auto">update</property>
 <property name="hibernate.show_sql">true</property>
 <property name="hibernate.format_sql">true</property>
 <property name="hibernate.use_sql_comments">true</property>
 <mapping
 class="com.darekzon.bookstore.domain.Account" />
 <mapping
 class="com.darekzon.bookstore.domain.AccountRole" />
 <mapping
 class="com.darekzon.bookstore.domain.Administrator" />
 </session-factory>
</hibernate-configuration>

Pliik ustawia kolejno:

1. hibernate.dialect -  jaki język zapytań będzie wykorzystywany (w tym wypadku rozszerzenia dodane przez postgresql)
2. hibernate.hbm2ddl.auto – automatycznie aktualizuj schemat bazy danych na podstawie class encji (super sprawa)
3. hibernate.show_sql – pokazuje zapytania sql jakie wykonuje hibernate (dobre przy debugowaniu, czasem wprowadza chaos do konsoli)
4. hibernate.format_sql – formatuje w/w zapytania, przydaje się
5. hibernate.user_sql_comments – dodatkowe komentarze, pomagają zorientować się jakie zapytanie aktualnie jest wykonywane
6. mapping class  – wskazanie jakie klasy traktowane są jako klasy encji (muszą być oznaczone adnotacją @Entity), wykorzystywane przy aktualizacji schematów

Drugim ważnym plikiem jest persistence.xml który konfiguruje nam PersistenceUnit czyli jednostę utrwalającą. Plik ten ma zawartość:

<persistence xmlns="http://java.sun.com/xml/ns/persistence"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
 version="2.0">
 <persistence-unit name="bookstorePU" transaction-type="RESOURCE_LOCAL">
 <provider>org.hibernate.ejb.HibernatePersistence</provider>
 <jta-data-source>bookstore</jta-data-source>
 <class>com.darekzon.bookstore.domain.Administrator</class>
 <class>com.darekzon.bookstore.domain.Account</class>
 <class>com.darekzon.bookstore.domain.AccountRole</class>
 </persistence-unit>
</persistence>

Określamy w nim nazwę jednostki utrwalającej, typ transakcji, dostawę jednostki oraz adres naszego źródła danych, musimy również wprowadzić informacje, które klasy będą używane podczas utrwalania (więc pewne dane się zdublują z plikiem hibernate.cfg.xml). Powyższy plik możemy umieścić w tym samym miejscu co plik hibernate.cfg.xml, tak by był dostępny dla JVM podczas ładowania aplikacji.

Gdy mamy już skonfigurowanego hibernate-a oraz jednostę utrwalającą, pora zintegrować je z naszą aplikacja, polegać to będzie na utworzeniu szeregu beanów odpowiedzialnych za obsługę żądań do bazy danych. Konfiguracja ta została zapisana w pliku web-data.xml i ma zawartość:

<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context"
 xmlns:tx="http://www.springframework.org/schema/tx" xmlns:mvc="http://www.springframework.org/schema/mvc"
 xmlns:jee="http://www.springframework.org/schema/jee"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.0.xsd http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-3.0.xsd">

 <jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/bookstore"
 cache="true" resource-ref="true" lookup-on-startup="false"
 proxy-interface="javax.sql.DataSource" />

<bean id="entityManagerFactory"
 class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
 <property name="dataSource" ref="dataSource" />
 </bean>

 <bean id="sessionFactory"
 class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
 <property name="dataSource" ref="dataSource" />
 <property name="configurationClass" value="org.hibernate.cfg.AnnotationConfiguration"/>
 <property name="configLocation" value="classpath:META-INF/hibernate.cfg.xml" />
 </bean>

 <bean id="transactionManager"
 class="org.springframework.orm.jpa.JpaTransactionManager">
 <property name="sessionFactory" ref="sessionFactory" />
 </bean>

 <bean id="templateManager"
class="org.springframework.orm.hibernate3.HibernateTemplate">
 <property name="sessionFactory" ref="sessionFactory" />
 </bean>

<tx:annotation-driven transaction-manager="transactionManager" />

</beans>

Konfiguracja zawiera:

dataSource:
Wyszukuje nasze połączenie (skonfigurowane w serwerze) i binduje je do nazwy dataSource

entityManager: manager encji

sessionFactory: można powiedzieć, że sesja jest tożsama (oznacza to samo) co połączenie z bazą danych. Dzięki podaniu klasy AnnotationConfiguration do parametru configurationClass mogę używać adnotacji do konfigurowania encji zamiast pisać pliki *.hba.xml. Parametr configLocation wskazuje miejsce gdzie znajduje się plik konfiguracyjny hibernate-a.

transactionManager: manager transakcji (raczej jasne)

templateManager: posiada szereg metod upraszczających obsługę ORM (wyszukiwanie, zapisywanie, aktualizacja, kasowanie etc.), do działania wymaga sesji podawanej w parametrze sessionFactory.

tx:annotation-driven: dzięki temu zapisowi możemy używać dodatkowych adnotacji (np. @Transactional)

Należy pamiętać by dopisać ścieżkę do konfiguracji  (/WEB-INF/web-data.xml) w pliku web.xml (w miejscu konfiguracji kontekstu).

Tak skonfigurowany spring, będzie lączył się przy starcie ze zdefiniowanym serwerem bazy danych, udostępnia również szereg obiektów pomagających w dostępie do bazy. Jeśli połączenie działa poprawnie (czyt. przy starcie nie wyskakuje żadne wyjątek) bierzemy się do dalszej pracy.

Obsługa wiadomości / tłumaczenia

Jestem zwolennikiem odcinania treści od formy, nie lubię gdy w kodzie strony widzę treści takie jak, nazwy pól, komunikaty błędów, czy też nagłówki. Takie podejście sprawia problem, gdy będziemy musieli zmienić tekst znajdujący się w wielu elementach aplikacji czy też co ważniejsze udostępnić aplikację w wielu językach.  Na szczęście istnieje proste rozwiązanie jakim jest mechanizm wiadomości. Mechanizm ten składa się z 3 elementów: konfiguracji wskazującej gdzie znajdują się teksty, pliku z tekstami oraz odpowiednich wstawek w kodzie aplikacji które wskazują jaka treść ma zostać umieszczona w danym miejscu.

Konfiguracja mechanizmu jest niezwykle prosta, polega na zdefiniowaniu nowego obiektu i przekazaniu mu listy plików w której znajdują się nasze wiadomości (poniżej):

<bean id="messageSource"
class="org.springframework.context.support.ResourceBundleMessageSource">
 <property name="basenames">
 <list>
 <value>/WEB-INF/messages/main</value>
 </list>
 </property>
 </bean>

Pewną nieścisłością jest fakt, że obiekt ten będzie przeszukiwał katalog /WEB-INF/messages/ w poszukiwaniu pliku main.properties, a nie jak można by sadzić pliku main, o czym trzeba pamiętać.

Nasz plik z wiadomościami ma prostą budowę, składa się z zestawu   klucz = treść, gdzie klucz jest unikalnym identyfikatorem nadawanym naszej treści, będzie on również używany w kodzie strony, gdzie należy wstawiać tagi w postaci <tag:message code=”IDENTYFIKATOR” /> który zostanie zastąpiony odpowiednią treścią. Proste w wygodne.

Dodawanie administratorów

Pierwszym zadaniem z jakim się zmierzymy jest dodawanie administratorów (w następnej części tutoriala zabezpieczymy nasz system, więc potrzebujemy konta by móc się zalogować), gdzie konta powinny spełniać wymagania:

1. hasło musi mieć przynajmniej 8 znaków, ale nie więcej jak 20 znaków
2. hasła zaszyfrowane zostaną algorytmem SHA-2 (odmiana sha256)
3. wykorzystana zostanie sól w postaci identyfikatora użytkownika (identyfikator nie będzie wystawiany na widok publiczny)
4. w bazie danych przechowywani będą użytkownicy o różnych poziomach dostępu, do panelu administracyjnego dostęp będą mieli tylko i wyłącznie Ci użytkownicy, którzy posiadają poziom ROLE_ADMIN

Z powyższych krótkich wymagań można łatwo wywnioskować, że potrzebujemy obiektu który będzie szyfrować ciągi znaków, oraz jednego do tworzenia soli. Obiekty te skonfigurowane zostaną w kolejnym pliku xml zapisanym pod nazwą security.xml, z racji, że są to obiekty wykorzystywane przy funkcjach bezpieczeństwa.
Plik ten aktualnie prezentuje się jak poniżej:

<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context"
 xmlns:tx="http://www.springframework.org/schema/tx" xmlns:mvc="http://www.springframework.org/schema/mvc"
 xmlns:jee="http://www.springframework.org/schema/jee"
 xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/jee

http://www.springframework.org/schema/jee/spring-jee-3.0.xsd

http://www.springframework.org/schema/context

http://www.springframework.org/schema/context/spring-context-3.0.xsd

http://www.springframework.org/schema/tx

http://www.springframework.org/schema/tx/spring-tx-3.0.xsd

http://www.springframework.org/schema/mvc

http://www.springframework.org/schema/mvc/spring-mvc-3.0.xsd">

 <bean id="passwordEncoder" class="org.springframework.security.authentication.encoding.ShaPasswordEncoder">
     <constructor-arg value="256"/>
 </bean>

 <bean id="saltSource" class="org.springframework.security.authentication.dao.ReflectionSaltSource">
     <property name="userPropertyToUse" value="id"/>
 </bean>

</beans>

Diagram klas struktury przechowującej dane nt. administratorów wygląda następująco:

Diagram klas - konta użytkowników

Klasa administratora (na razie pusta) rozszerza klasę użytkownika która posiada login oraz hasło jako dane uwierzytelniające, dodatkowo użytkownik agreguje poziom dostępu użytkownika (z racji, że w tej samej tabeli przechowywani będą administratorzy, operatorzy oraz zwykli użytkownicy) który wydelegowany jest do oddzielnej klasy.

Tworzymy Encje

Powyższy diagram musimy przepisać na klasy encji, najprościej mówiąc encja to obiekt reprezentujący jeden rekord jednej tabeli, tak więc Encja Account będzie odzwierciedleniem strukturę tabeli account.

Encje jakie utworzyliśmy podczas projektu powinny wyglądać tak:

Administrator (pełna zawartość pliku w repozytorium – zobacz koniec wpisu):

@Table(name = "administrator")
@Entity
public class Administrator extends Account { }

Account (pełna zawartość pliku w repozytorium – zobacz koniec wpisu):

@Entity
@Table(name = "account")
@Inheritance(strategy = InheritanceType.JOINED)
public class Account {

 @Id
 @GeneratedValue(generator = "account_id", strategy = GenerationType.SEQUENCE)
 @SequenceGenerator(name = "account_id", sequenceName = "account_id_seq")
 Integer id;

 public Integer getId() {
 return id;
 }

 public void setId(Integer id) {
 this.id = id;
 }

 @Basic
 @NotNull
 @Size(min = 5, max = 20)
 String username;

 public String getUsername() {
 return username;
 }

 public void setUsername(String username) {
 this.username = username;
 }

 @Basic
 @Size(min = 8, max = 20)
 String password;

 public String getPassword() {
 return password;
 }

 public void setPassword(String password) {
 this.password = password;
 }

 @Transient
 public String repeatedPassword;

 public String getRepeatedPassword() {
 return repeatedPassword;
 }

 public void setRepeatedPassword(String repeatedPassword) {
 this.repeatedPassword = repeatedPassword;
 }

 @Basic
 @DateTimeFormat(iso = ISO.DATE_TIME)
 Date addDate = new Date();

 public Date getAddDate() {
 return addDate;
 }

 public void setAddDate(Date addDate) {
 this.addDate = addDate;
 }

 @OneToMany(cascade = CascadeType.ALL, mappedBy = "account", fetch = FetchType.EAGER, targetEntity = AccountRole.class)
 List<AccountRole> accountRole = new ArrayList<AccountRole>();

 public List<AccountRole> getAccountRole() {
 return accountRole;
 }

 public void setAccountRole(List<AccountRole> accountRole) {
 for (AccountRole ar : accountRole) {
 this.addAccountRole(ar);
 }
 }

 public void addAccountRole(AccountRole accountRole) {
 if (!this.accountRole.contains(accountRole)) {
 accountRole.setAccount(this);
 this.accountRole.add(accountRole);
 }
 }
}

AccountRole (pełna zawartość pliku w repozytorium – zobacz koniec wpisu):

@Entity
@Table(name = "account_role")
public class AccountRole {

 public AccountRole() {
 this.setRole("ROLE_ANONYMOUS");
 }

 public AccountRole(String role) {
 this.setRole(role);
 }

 @Id
 @GeneratedValue(generator = "role_id", strategy = GenerationType.SEQUENCE)
 @SequenceGenerator(name = "role_id", sequenceName = "account_role_id_seq", initialValue = 1)
 Integer roleId;

 public Integer getRoleId() {
 return roleId;
 }

 public void setRoleId(Integer roleId) {
 this.roleId = roleId;
 }

 @Basic
 String role;

 public String getRole() {
 return role;
 }

 public void setRole(String role) {
 this.role = role;
 }

 @ManyToOne(targetEntity = Account.class, cascade = CascadeType.ALL, fetch = FetchType.LAZY)
 @JoinColumn(name = "accountId", nullable = true)
 Account account;

 public Account getAccount() {
 return account;
 }

 public void setAccount(Account account) {
 this.account = account;
 }

}

Warto zwrócić uwagę na adnotacje:

1. @Entity – oznacza, że dana klasa jest klasą encyjną
2. @Table – mówi jaka tabela w bazie odpowiada naszej encji (jeśli ustawimy, hibernate automatycznie wyeksportuje naszą encje do danej tabeli)
3. @Inheritance – mówi hibernate-owi, że ewentualne zależności (poprzez dziedziczenie) powinny być zapisywane w osobnych tabelach (UWAGA! – domyślnie, hibernate łączy wszelkie zależności w jednej tabeli), mechanizm sam zadba o odpowiednie klucze obce.
4. @Id – oznacza wybrane pole jako identyfikator
5. @GeneratedValue – konfiguruje metodę generowania wartości dla pola, wykorzystywany w identyfikatorach (autoincrement)
6. @SequenceGenerator – konfiguruje generator sekwencji dla wybranego pola
7. @Basic – zwykłe pole
8. @Transistent – mówi aplikacji, że dane pole nie jest odzwierciedlone w bazie danych
9. @DateTimeFormat – ustala format daty, dla pola które datę będzie przechowywać
10. @ManyToOne – tworzy relacje wiele-do-jednego
11. @OneToMany – tworzy relacje jeden-do-wielu
12. @JoinColumn – ustawia kolumnę łączącą dwie tabele

Ostatnie adnotacje posłużyły do skonfigurowania relacji Konto->Poziom dostępu, dzięki temu przy pobieraniu informacji o koncie, automatycznie dostaniemy listę poziomów dostępu jakie posiada użytkownik.

Drugą ważną rzeczą w powyższych klasach encji są adnotacje służące walidowaniu Dzięki nim nie musimy zaśmiecać kontrolerów dodatkowymi regułami sprawdzającymi, czy też konfigurować walidacji przez XML, reguły walidacji to kolejno:

1. @NotNull – pole nie może być nullem
2. @Size – wielkość pola musi mieścić się w granicach min do max znaków

Oczywiście, to nie jedyne walidatory jakie są dostępne, pełną listę podstawowych walidatorów znajdziecie w dokumentacji.

Dodawanie administratorów będzie zapisane w kontrolerze AdministratorController, na początek zaimplementujemy metodę która będzie wyświetlać formularz rejestracyjny.

AdministratorController (pełna zawartość pliku w repozytorium – zobacz koniec wpisu):

@Controller
public class AdministratorController {

 @Autowired
 AccountService accountService;

 @RequestMapping(value = "/administrator/add", method = RequestMethod.GET)
 public ModelAndView add() {
 ModelAndView mav = new ModelAndView("/administrator/add");
 mav.addObject("administrator", new Administrator());
 return mav;
 }

}

Co warto zauważyć?

1. @Controler – każdy kontroler oznaczony musi być adnotacją @Controler, dzięki czemu spring podczas skanowania pakietu dodaje go do listy
2. @Autowired - mówi Spring-owi aby poszukał obiektu o zadanym typie i automatycznie podpiął go do pola
3. @RequestMapping – mówi springowi jakie żądanie ma być skierowane do danej metody, opcja RequestType wskazuje dodatkowo jaki typ żądania ma być tam skierowane,w tym przypadku zależy nam na żądaniu GET

Powyższa metoda zwraca obiekt ModelAndView (standardowy obiekt zwracany przez większość metod) który przechowuje informacje na temat pliku widok oraz obiekt klasy Administrator, obiekt ten zbindujemy w widoku dzięki czemu wartości pól w formularzu zostaną przepisane do odpowiadających im wartości pól w obiekcie.
Widok formularza prezentuje się następująco:

<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form" %>
<%@ taglib prefix="tag" uri="http://www.springframework.org/tags" %>
<div>
 <form:form commandName="administrator">
 <ol>
 <li>
 <form:label path="username"><tag:message code="administrator.username" /></form:label>
 <form:input path="username" />
 <form:errors path="username" />
 </li>
 <li>
 <form:label path="password"><tag:message code="administrator.password" /></form:label>
 <form:password path="password" />
 <form:errors path="password" />
 </li>
 <li>
 <form:label path="repeatedPassword"><tag:message code="administrator.repeatedPassword" /></form:label>
 <form:password path="repeatedPassword" />
 <form:errors path="repeatedPassword" />
 </li>
 <li>
 <input type="submit" />
 </li>
 </ol>
 </form:form>
</div>

Gdzie:

• taglib – pozwala stosować rozszerzenia w JSP; form-generowanie formularzy, obsługa błedów, tag-wyświetlanie wiadomości o których wspomniałem wcześniej
• commandName – to nazwa nadana naszemu obiektowi podczas przekazywania go z kontrolera do widoku,
• input path – to pole w naszym obiekcie
• errors – lista błędów dla danego pola (pojawia się po walidacji)

Powyższy formularz prezentuje się następująco:

Formularz dodawania administratora

Po wciśnięciu wyślij, dane z formularza już pod postacią obiektu klasy Administrator przekazywane są do kolejnej metody która sprawdza poprawność danych, i jeśli wszystko jest jak trzeba zapisuje je. Metoda ta wygląda następująco (pełna zawartość pliku w repozytorium – zobacz koniec posta):

@RequestMapping(value = "/administrator/add", method = RequestMethod.POST)
 public ModelAndView add(@Valid Administrator admin, BindingResult result) {
 ModelAndView mav = new ModelAndView("administrator/add");
 if (!admin.getPassword().equals(admin.getRepeatedPassword())) {
 result.addError(new FieldError("administrator", "repeatedPassword",
 "notEqual"));
 }
 if (result.hasErrors()) {
 mav.addObject("administrator", admin);
 return mav;
 }
 List<AccountRole> ar = new ArrayList<AccountRole>();
 ar.add(new AccountRole("ROLE_ADMIN"));
 try {
 accountService.registerAccount(admin, ar);
 } catch (UserExistsException e) {
 result.reject("user.exists");
 mav.addObject("administrator", admin);
 return mav;
 }
 mav.setViewName("redirect:/administrator.html");
 return mav;
 }

Powyższa metoda przyjmuje dwa argumenty, pierwszym jest nasz obiekt Administrator który zawiera dane z formularza, oraz obiekt BindingResult który przechowuje informacje na temat ewentualnych błędów które wystąpiły podczas sprawdzania poprawności (zgodnie z adnotacjami w klasach encyjnych). Aby Spring wiedział, że dany obiekt wymaga sprawdzenia poprawności danych należy oznaczyć go adnotacją @Valid, dzięki temu, spring automatycznie sprawdzi obiekt, a błędy zapisze w obiekcie BindingResult.

Ponieważ nie istnieje adnotacja walidacyjna (przynajmniej w podstawowym zestawie) która sprawdza czy dwa pola są identyczne musiałem zaprogramować dodatkowe sprawdzanie już w kontrolerze. Gdy akcja wykryje, że hasło oraz jego powtórzona wartość nie są identyczne, doda do obiektu BindingResult błąd dla pola repeatedPassword przez co formularz nie zostanie zapisany w bazie, a zamiast tego zostanie ponownie wyświetlony z zaznaczonym błędem, jak przykład poniżej:

Formularz z błędnymi polami

Jeśli natomiast wszystkie nasze pola zostaną wypełnione poprawnie nastąpi próba zapisania formularza accountService.registerAccount, a po poprawnym zapisaniu zostaniemy przekierowani (dyrektywa „redirect:/administrator”) do strony /administrator.html. Akcja rejestracji nowego administratora składa się z 2 plików (nie wliczając interfejsów które te pliki implementują.

Pierwszy plik to AccountServiceImpl który jest w tym wypadku głównym plikiem (pełna zawartość pliku w repozytorium – zobacz koniec posta):

@Transactional
@Repository
public class AccountServiceImpl implements AccountService {
 @Autowired
 AccountDao accountDao;

 @Autowired
 PasswordEncoder passwordEncoder;

 @Autowired
 SaltSource saltSource;

 @PersistenceContext
 EntityManager entityManager;

 @Override
 public void registerAccount(Account account,List<AccountRole> ar) throws UserExistsException {
 try{
 accountDao.findUsername(account.getUsername());
 throw new UserExistsException();
 }catch(UserNotFoundException une){
 entityManager.persist(account);
 account.setPassword(passwordEncoder.encodePassword(account.getPassword(), saltSource));
 for(AccountRole arole : ar){
 account.addAccountRole(arole);
 }
 entityManager.flush();
 }

 }

}

Nasza klasa oznaczona została dwoma adnotacjami, @Transactional, która mówi że, wszystkie metody w niej zaimplementowane objęte są transakcją, oraz @Repository które pozwala nam na pobranie managera encji poprzez adnotację @PersistenceContext.

Aby nasza metoda działała poprawnie musimy dostarczyć jej obiekt accountDao który posłuży do sprawdzenia czy dany użytkownik już istnieje, manager encji który zapisze nasz obiekt w bacie, a także obiekty passwordEncoder oraz saltSource służące szyfrowaniu hasła.

Po wywołaniu metody obiekt accountDao znajduje użytkownika o podanej nazwie użytkownika i jeśli go nie znajdzie wyrzuca wyjątek UserNotFoundException i gdy ten wyjątek wystąpi możemy zapisywać użytkownika do bazy. Nasz administrator zapisywany jest metodą persist z obiektu entityManager. Dzięki tej metodzie nasza encja zostanie tymczasowo związana z rekordem w bazie danych co oznacza, że wszelkie modyfikacje administratora będą automatyczne odzwierciedlane w bazie danych (więcej o cyklu życia encji w dokumentacji). Gdy nasz użytkownik zostanie zapisany musimy zaktualizować mu hasło, dzieje się tak, gdyż hasło szyfrowane algorytmem sha256 z dodatkową solą w postaci identyfikatora użytkownika, który nadawany jest dopiero po zapisaniu go do bazy danych.

Po aktualizacji hasła przypisujemy naszemu użytkownikowi odpowiednie poziomy dostępu (może mieć ich więcej jak jeden) poprzez dodanie obiektów AccountRole do obiektu Administrator (dane zostają zapisane dzięki wcześniejszemu skonfigurowaniu powiązań @ManyToOne i @OneToMany).

Ciekawie wygląda również plik AccountDaoImpl który wyszukuje użytkowników po zadanym loginie (pełna zawartość pliku w repozytorium – zobacz koniec posta):

 public class AccountDaoImpl implements AccountDao {

 @Autowired
 HibernateTemplate template;

 @Autowired
 SessionFactory session;

 public Account findUsername(String username) throws  UserNotFoundException {
 DetachedCriteria dc = DetachedCriteria.forClass(Account.class);
 dc.add(Property.forName("username").eq(username));
 List users = template.findByCriteria(dc, 0, 1);

 if (users.size() > 0) {
 return (Account) users.get(0);
 }

 throw new UserNotFoundException();
 }

 }

W ciele metody findUsername zastosowane zostało wyszukiwanie po kryteriach, CriteriaApi daje ogromne możliwości w dynamicznym budowaniu zapytań do bazy, w naszym przypadku wskazaliśmy, że dane zapytanie dotyczyć będzie klasy Account (a tym samym tabeli odzwierciedlającej tą klasę), oraz dodaliśmy właściwość pola username ustalając że pole to powinno być równe wartości podanej w argumencie.

Wyświetlamy użytkowników

Jeśli nasi administratorzy zostali zapisani do bazy, warto by ich wyświetlić w liście, w tym celu stworzymy metodę obsługującą żądanie /administrator.html. Metoda ta znajduje się w pliku AdministratorController i wygląda następująco:

@RequestMapping(value = "/administrator")
 public ModelAndView index() {
 ModelAndView mav = new ModelAndView("/administrator/index");
 List<String> roles = new ArrayList<String>();
 roles.add("ROLE_ADMIN");
 List<Account> acc = accountService.listAccounts(roles);
 mav.addObject("accounts", acc);
 return mav;
 }

Metoda listująca pobiera z bazy wszystkich użytkowników o zadanym poziomie dostępu (AccountRole) po czym przekazujemy listę do widoku. Metoda wyszukująca użytkowników zaimplementowana jest w dwóch plikach, pierwszy AccountServiceImpl poniżej:

@Override
 @Transactional(readOnly=true)
 public List<Account> listAccounts(List<String> roles) {
 return accountDao.listAccounts(roles);
 }

Ma jedynie za zadanie wywołać metodę wyszukującą z obiektu AccountDaoImpl, warto wyjaśnić adnotację @Transactional, ponieważ wszystkie metody w klasie AccountServiceImpl objęte są transakcją warto przy metodach które nie zapisują danych zaznaczyć, że transakcja ma być traktowana jako tylko do odczytu, dzięki temu zyskujemy na wydajności.

Metoda wywołana przez powyższą metodę ma postać:

@Override
public List listAccounts(List roles) {
Criteria criteria = session.openSession().createCriteria(Account.class);
criteria.addOrder(Order.asc(„username”));
criteria.createCriteria(„accountRole”).add(Restrictions.in(„role”,roles));
return criteria.list();
}

Również tutaj zastosowanie znalazły kryteria, choć w troszkę inny sposób. W tym przypadku wyszukujemy danych dla klasy Account sortując je (criteria.addOrder) według nazwy użytkownika, przy czym wszystkie zwracane rekordy powinny posiadać powiązany rekord z tabeli reprezentowanej przez obiekt accountRole który pole role ma zadaną wartość (tu ROLE_ADMIN). Ponieważ do wyszukania poziomów dostępu musimy złączyć dwie tabele robimy to poprzez stworzenie nowych cryteriów „na obiekcie” już aktywnych kryteriów.

UPDATE 1

W komentarzach zauważyliście, że w aplikacji mieszam JPA z hibernatem, aby to poprawić stworzyłem nową metodę z wykorzystaniem JPA QL:

@Override
 public Collection<Account> listAccounts(Collection<AccountRole> roles){
 List<String> c = new ArrayList<String>(roles.size());
 for(AccountRole in : roles){
 c.add(in.getRole());
 }
 List<Account> accounts = entityManager.createQuery("SELECT a FROM Account a JOIN a.accountRole r WHERE r.role IN(?1)",Account.class).setParameter(1,c).getResultList();
 return accounts;
 }

Powyższa metoda przyjmuje jako argument kolekcję ról do jakich muszą należeć konta które pobieramy. Kolekcję obiektów musimy przekrztałcić na kolekcję prymitywów (w naszym wypadku ciągów znaków – STRING).
Następnie przy pomocy managera encji (entityManager) tworzymy zapytanie (createQuery) które przyjmuje tylko jeden parametr przekazywany poprzez setParameter.

Gdy znajdziemy wszystkich użytkowników przekazujemy ich listę do widoku i generujemy:

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

<c:choose>
 <c:when test="${not empty accounts}">
 <c:forEach items="${accounts}" var="account" varStatus="status">
 ${status.index} ${account.username}
 </c:forEach>
 </c:when>
 <c:otherwise>
 <tag:message code="list.no-entry" />
 </c:otherwise>
</c:choose>

Co dalej

W kolejnej części tutoriala postaramy się zabezpieczyć nasz panel administracyjny poprzez zastosowanie SpringSecurity, ponieważ w tej chwili panel administracyjny wygląda biednie, wykorzystamy sitemesh, jsp oraz html by poprawić jego wygląd. A jeśli zostanie trochę miejsca i czasu zajmiemy się…. (może niespodzianka)

PS. Zauważyłem, że ta część tutoriala zajęła mi dużo czasu, postanowiłem rozbić go na mniejsze ale częściej występujące wpisy.

Jak pobrać projekt

Projekt został umieszczony na serwerach GitHub.com. Adres bezpośredni do projektu: https://github.com/darek/bookstore.
Dodatkowo zostało uruchomione repozytorium GIT dla wszystkich chętnych i dostępny jest pod adresem: git://github.com/darek/bookstore.git

1. Gdzie TOMCAT_HOME jest katalogiem głównym tomcata

Zanim przystąpimy do tworzenia projektu warto odpowiednio przygotować sobie zaplecze techniczne. Z racji, że w eclipse pisze znaczna część firm (przynajmniej polskich), a ja jeszcze z niego nie korzystałem w tego typu projektach postanowiłem, że to będzie dobry moment by się z nim zmierzyć.
Eclipse wyposażony zostanie dodatkowo we wtyczkę m2Eclipse która pomoże mi w zarządzaniu maven-em. Aplikacja uruchomiona zostanie na kontenerze aplikacji Tomcat, a dane przechowam w bazie PostreSQL. Z racji, że źródła umieszczane będą w zewnętrznym repozytorium opartym o GIT potrzebny jest też ten właśnie program, ja preferuję korzystać z gita poprzez konsolę, oczywiście jeśli ktoś woli można doinstalować odpowiednią wtyczkę bądź nakładkę graficzną.

Co przyda się przy tworzeniu:

• Eclipse
• maven2 i plugin m2Eclipse
• Tomcat 6
• PostgreSQL
• GIT
• Hudson - bo czemu nie

Podstawowe założenia

Aplikacja składać się będzie z dwóch modułów, panelu administracyjnego dostępnego tylko i wyłącznie dla użytkowników z poziomem dostępu ADMIN oraz części otwartej do której dostęp będą mieli wszyscy internauci (za wyjątkiem obszarów które będą wymagały zalogowania się z poziomem dostępu CLIENT). Podział taki można wykonać na dwa sposoby, pierwszym jest stworzenie jednego projektu w którym dokonamy logicznego podziału widoków jak i kontrolerów na panel administracyjny oraz strefę otwartą, spring security dodatkowo zabezpieczy wejście. Wyniki składane będą przez sitemesh dzięki któremu można stworzyć oddzielny layout dla panelu administracyjnego oraz dla części otwartej. Jedynym plusem tego rozwiązania jest łatwość operowania plikami w projekcie(o ile nie jest duży), wszystko mamy w jednym miejscu dzięki czemu nie trzeba przechodzić między projektami i szukać plików jeśli tylko chcemy coś zmienić. Niestety przeciw temu rozwiązaniu jest cała reszta, kod staje się mniej czytelny, potrzebne są dodatkowe obejścia które rozdzielać będą żądania do panelu administracyjnego jak i strony klienckiej, nie możliwe jest również umieszczenie osobno części administracyjnej na np. naszym serwerze wewnętrznym. Pomimo tego, że pliki poukładane mamy w jednym projekcie co z początku może wydawać się plusem w większych projektach staje się zmorą, gdyż większa ilość plików powoduje utrudnienia w odszukaniu tego który chcemy zmodyfikować (wiem, przeżyłem to na własnej skórze).

Drugim rozwiązaniem jest stworzenie osobnych projektów dla panelu administracyjnego oraz części klienckiej. Dzięki takiemu rozwiązaniu zachowujemy pewien ład i porządek w strukturze folderów projektów oraz plikach (mniej plików mniej problemu). Dzięki rozdzieleniu plików konfiguracyjnych zyskujemy większą elastyczność oraz możliwość łatwiejszego dostosowania ustawień. Część wspólna obu projektów (klasy związane z obiektami bazy danych) trzymane są w projekcie który dołączany jest jako biblioteka. Mój wybór padł właśnie na tą metodę.

Podsumowując, utworzone zostaną 3 projekty: bookstore, bookstore-admin oraz bookstore-lib.

Zaczynamy

Projekt zaczniemy od stworzenia prostej strony a’la Witaj Świecie!. Aby zacząć całą zabawę otwieramy Eclipse i tworzymy nowy projekt typu „Dynamic Web Project” (File -> New -> Project… -> Web -> Dynamic Web Project). Następnie wpisujemy nazwę projektu i klikamy finish.
Gdy nasz projekt zostanie utworzony musimy dodać do niego obsługę mavena. Jeśli mamy zainstalowaną wtyczkę m2Eclipse wystarczy kliknąć prawym klawiszem myszy na nasz projekt i wybrać odpowiednio Maven -> Enable Dependency Managment. Plugin doda do naszego projektu plik pom.xml, który zawiera wszelkie informacje potrzebne dla maven-a. W strukturze projektu możemy zauważyć folder WebContent który zawierać będzie pliki konfiguracyjne, tłumaczące, pliki jsp oraz wszystko co potrzebne do wyświetlania wyników. Ponieważ nazwa folderu nie przypadła mi do gustu zamieniłem ją na war (co będziecie mogli zobaczyć po pobraniu projektu).

Struktura projektu z uruchomioną opcją Dependency Managment

Dodawanie zależności

Pierwszą rzeczą jaką robię w nowo utworzonym projekcie jest dodanie podstawowych zależności. Z mojej strony są to takie biblioteki jak sitemesh 3 (UWAGA! – wydanie alpha, mam nadzieję, że działa), spring-web, spring-context, czy też spring-webmvc; czyli wszystko co potrzebne na dobry początek.
Na koniec dodaję biblioteki JUnit oraz Mockito które posłużą do testowania aplikacji. Ponieważ biblioteki te nie będą nam potrzebne w działającej aplikacji, warto zaznaczyć w ich zakresie (ang. scope) opcje „test” dzięki czemu będą dołączane tylko podczas testów.

Zarządzanie zależnościami w Eclipse

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"

id="b0ok" version="2.5">

<display-name>bookstore</display-name>

<!--

wskazujemy lokalizacje plikow konfiguracyjnych

-->

<context-param>

<param-name>contextConfigLocation</param-name>

<param-value>

/WEB-INF/web-servlet.xml

</param-value>

</context-param>

<listener>

<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>

</listener>

<!--

tworzymy servlet ktory obslugiwac bedzie nasze zapytania

-->

<servlet>

<servlet-name>web</servlet-name>

<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>

</servlet>

<!--

ustalamy ze nasz servlet obslugiwac bedzie tylko zapytania konczace

sie rozszerzeniem *.html

-->

<servlet-mapping>

<servlet-name>web</servlet-name>

<url-pattern>*.html</url-pattern>

</servlet-mapping>

<!--

ustalamy, jakie pliki beda ladowane gdy aplikacja dostanie zapyanie

"/" (np. http://example.com/)

-->

<welcome-file-list>

<welcome-file>redirect.jsp</welcome-file>

</welcome-file-list>

</web-app>

<%@ page contentType="text/html;charset=UTF-8" language="java"%>

<jsp:forward page="/index.html" />

Update 1:
Jak trafnie zauważył Chlebik (zob. komentarz), zamiast redirect.jsp możemy śmiało napisać „index.html” wtedy spring wykona akcję przeznaczoną dla żądania „/”, przy czym, należy dodać plik index.html do głównego katalogu (war/webContent) aplikacji, może być nawet pusty, ważne by spring wiedział, że jest. Za podpowiedź dziękuję.

Plik web-servlet.xml na początek wskażemy gdzie aplikacja ma szukać kontrolerów, oraz zaznaczymy, że będzie ona działała w oparciu o adnotacje.
web-servlet.xml

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context"
xmlns:tx="http://www.springframework.org/schema/tx" xmlns:mvc="http://www.springframework.org/schema/mvc"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.0.xsd http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-3.0.xsd">
<context:component-scan base-package="com.darekzon.bookstore.controller" />
<context:annotation-config />
<context:spring-configured />
<bean
class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="prefix" value="/views/" />
<property name="suffix" value=".jsp" />
</bean>
</beans>

W sekcji <context:component-scan> wskazujemy, który pakiet ma być skanowany w poszukiwaniu kontrolerów (klas z adnotacją @Controller), jeśli chcemy możemy wskazać więcej jak jeden pakiet przy czym trzeba pamiętać, że nazwy klas muszę się różnić, więc jeśli mamy IndexController w naszym pakiecie to w pakiecie com.darekzon.bookstore.controller musimy umieścić Index2Controller.

Ach, no i ostatni blok wskazuje gdzie spring ma szukać plików jsp za pomocą których generować będzie wyniki.

Pierwszy kontroler

Aplikacja skonfigurowana, pierwszy kontroler będzie wyświetlał legendarny napis „Witaj świecie!”. Sam kontroler jest wyjątkowo prosty, posiada tylko jedną metodę, która zwraca obiekt typu „ModelAndView” przechowujący nazwę widoku do wyrenderowania. Kontroler zapisany jest w pliku IndexController.java (konwencja nazewnicza nie jest obowiązkowa) a jego zawartość przedstawia się jak poniżej:

package com.darekzon.bookstore.controller;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.servlet.ModelAndView;

@Controller
public class IndexController {

@RequestMapping(value = "/index")
public ModelAndView index(){
ModelAndView mav = new ModelAndView("index/index");

return mav;
}

}

Warto tutaj zwrócić uwagę na 3 rzeczy:

1. Każdy kontroler powinien mieć adnotację @Controller, dzięki temu spring podczas skanowania pakietów (zob. konfigurację web-servlet.xml ↑)
2. Spring szuka metody którą ma wykonać na podstawie adnotacji @RequestMapping, w naszym przypadku czeka aż wywołamy żądanie „/index„,  warto dodać, że nie można dodać dwóch metod z tą samą wartością tej adnotacji (podczas uruchamiania wyskoczy wyjątek)
3. W tym przypadku zwracamy obiekt ModelAndView który zawiera nazwę pliku widoków który posłuży do renderowania wyników, plik widoku powinien znajdować się w folderze /views/index/index.jsp, czyli według ustawień w pliku web-servlet.xml oraz wartości zwracanej przez metodę.

Kontroler gotowy, pora na widok który będzie renderowany, ponieważ będzie to wyświetlenie tekstu „Witaj świecie!” plik ten nie jest skomplikowany (kolejne na pewno wniosą coś nowego w tej kwestii), a jego zawartość przedstawia się następująco:

<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%>
<html>
<head>
<title>Index</title>
</head>
<body>
Witaj świecie!
</body>
</html>

Tu tłumaczyć raczej nic nie trzeba, no może poza faktem pisania kodu całej strony w wyniku, ale o tym za chwilę.

Sitemesh i konfiguracja szablonów

Sitemesh to ciekawy projekt dzięki któremu znacznie ułatwimy sobie zabawę z wyglądem strony, jego głównym zadaniem jest sklejanie widoków wygenerowanych przez „aplikację” z ogólnym szablonem, oraz doklejanie części wspólnych między widokami (np. mamy oddzielny layout dla strony głównej, kontaktu oraz reszty serwisu, przy czym menu jest takie samo).

„]

Sposób działania Sitemesh-a[1

W projekcie użyję najnowszej (3.0alpha-1) wersji sitemesh-a, ponieważ nie jest to jeszcze stabilna wersja (nawet nie beta), zalecam do poważnych projektów używać wersję 2.4 dostępną pod starą stroną projektu.

Konfiguracja sitemesh-a może odbywać się na dwa sposoby: klasa Java rozszerzająca klasę ConfigurableSiteMeshFilter lub plik XML, ponieważ z niewiadomych przyczyn konfiguracja przez XML mi nie działa skupię się na konfigurowaniu z wykorzystaniem JAVY.

W pliku web.xml musimy dodać filtry które będą go uruchamiać dla każdego żądania (przynajmniej w moim przypadku), wskazując przy tym naszą klasę konfigurującą, kod wygląda następująco:

<filter>
<filter-name>sitemesh</filter-name>
<filter-class>com.darekzon.bookstore.filter.Sitemesh</filter-class>
</filter>
<filter-mapping>
<filter-name>sitemesh</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

Zaś klasa Sitemesh konfigurująca ma postać:

public class Sitemeshextends ConfigurableSiteMeshFilter {
@Override
protected void applyCustomConfiguration(SiteMeshFilterBuilder builder) {
builder.addDecoratorPath("/*", "/views/layout/default.jsp");
}
}

Działanie proste, przechwytujemy wyniki żądań wysłanych do aplikacji, i „kompilujemy” je z dekoratorem z pliku „/views/layout/default.jsp” (UWAGA! powinno podawać się pliki z rozszerzeniami innymi od tych zdefiniowanych w filtrach w pliku web.xml – w moim wypadku .html).

W tej chwili dekorator wygląda następująco:

<!doctype html>
<html lang="pl" dir="ltr">
<head>
<title><sitemesh:write property='title' /> - BookStore</title>
<link rel="stylesheet" href="/resource/style/default.css" />
<sitemesh:write property='head' />
</head>
<body>
<sitemesh:write property='body' />
</body>
</html>

Podczas renderowania sitemesh otwiera dekorator oraz plik wynikowy kontrolera oraz je scala (nie chodzi o język programowania), w miejscu tagu <sitemesh:write property=’title’ /> wstawia wartość tagu <title> wyrenderowanego wyniku, w miejsce tagu <sitemesh:write property=’head’ /> wartość tagu head (za wyjątkiem title), a tam gdzie pyta o <sitemesh:write property=’body’ />, wszystko co znajduje się w body. Proste, a co ważne wygodne.

CDN…

W następnej części zajmiemy się panelem administracyjnym oraz jego zabezpieczeniem, stworzymy również cały layout tego panelu wykorzystując bardziej zaawansowane techniki dostarczane przez JSP i Sitemesh.Tymczasem zapraszam do pozostawiania komentarzy, wszelkie postaram się wziąć pod uwagę.

Jak pobrać projekt

Projekt został umieszczony na serwerach GitHub.com. Adres bezpośredni do projektu: https://github.com/darek/bookstore.
Dodatkowo zostało uruchomione repozytorium GIT dla wszystkich chętnych i dostępny jest pod adresem: git://github.com/darek/bookstore.git

^1. Diagram pobrany ze strony http://www.sitemesh.org/overview.html

Największym minusem podczas nauki Spring Framework był brak kompleksowych przykładów pokazujących jak zbudować pełną aplikację wykorzystując nie tylko Spring-a, ale również integrując z nim inne rozwiązania.

Ten tutorial ma za zadanie uzupełnić tą lukę, choć jego zadanie jest troszkę większe. Pisząc tutorial mam zamiar nie tylko pokazać jak wygląda taka aplikacja, ale również skonsolidować swoją wiedzę oraz nauczyć się czegoś więcej od was (choćby poprzez komentarze). Myślę, że będzie to dobre miejsce na wszelkie dyskusje na temat technologii użytych w projekcie oraz sposobu ich użycia. Z chęcią przyjmę również wszelką KONSTRUKTYWNĄ krytykę.

Projekt jaki tutaj zrealizuje to księgarnia internetowa (helion może zacząć się bać ;) ) która na początku oferować będzie standardowe funkcjonalności (kategorie, książki, wyszukiwarkę, mechanizm zamawiania). Szerzej opiszę wszystko w następnych częściach tutorialu.

W projekcie mam zamiar wykorzystać:

• Spring Framework 3.0
• Hibernate + Hibernate Search (implementacja wyszukiwarki Lucene)
• Jasypt
• Sitemesh
• inne o których jeszcze nie wiem
• Lucene (indeksowanie/wyszukiwanie zawartości)
• inne

Wkrótce podam również adres do repozytorium projektu który umieszczony będzie na serwerach kenai.com (wkrótce w strukturach java.net)

Choć stworzenie dużego javovego projektu jest możliwe w zwykłym notatniku (pomijając kompilację oraz serwer obsługujący) jest to raczej mało wygodne a na pewno nie wydajne. Do tej pory zazwyczaj używałem NetBeans-a jako, że głównie piszę aplikacje desktopowe. Jednak do tego zadania potrzebuję czegoś więcej tak więc mój wybór padł na:InteliJ Idea będzie IDE które wesprze mnie w tworzeniu aplikacji JEE. Dlaczego ten wybór? Może na początku dlaczego nie. Wcześniej korzystałem z Eclipse jednak jego sposób konfiguracji lekko mnie przeraził, trzeba się naprawdę porządnie na klikać, żeby coś tam dodać (może teraz jest lepiej), jeśli chodzi o NetBeans w dziedzinie EE dopiero rozpoczyna swoją przygodę (wreszcie naprawdę porządnie skupili się na tej funkcjonalności), niedawna aktualizacja do wersji 6 oraz 6.5(i zapewne przyszła 7) przyniosła naprawdę wiele udogodnień jeśli chodzi o pisanie aplikacji enterprise-owych jednak na ten moment nadal zawiera błędy (albo ja się nie znam – co w sumie jest prawdą).

Samo InteliJ Idea jest całkiem miłym środowiskiem, wspiera wszystkie technologie które będę używał w moim projekcie (Spring, Hibernate, SOAP), ma wsparcie dla maven-a a także systemu kontroli wersji GIT. Ma bardzo dobry mechanizm podpowiadania składni (szczególnie xml-i), co dodatkowo ułatwia programowanie.

W części desktopowej skorzystam z NetBeans platform, jest to głównie wina Marka Klisia który na NetBeans Day w Krakowie pokazywał możliwości tej platformy. Dodam, że przy okazji ostatnich zaliczeń semestralnych stworzyłem niewielką aplikację w tym swing-owym framework-u i muszę przyznać, że naprawde przyśpiesza wszelkie prace (choćby zarządzanie oknami, czy też mechanizm aktualizacji).

Z racji, że moja praca ma zawierać metody projektowania trzeba będzie stworzyć trochę UML-i, do tego zadania wykorzystam aplikację Visual Paradigm for UML. Wybór był raczej jasny, środowisko to dostarcza pełną obsługę chyba wszystkich dostępnych typów UML-i, do tego jest wygodne w użyciu.

Żeby ogarnąć to wszystko wykorzystam projekt Maven. Maven jest zarządcą projektów opartym o metodologię POM. Pomoże mi w zarządzaniu bibliotekami wykorzystywanymi w mojej aplikacji (kolejny plik xml dochodzi do rodziny).

Wcześniej wspomniany GIT zabezpieczy mnie przed wszelkimi błędami programistycznymi(usunę to, chyba jest nie przydatne ;) ) a także błędami ze strony systemu operacyjnego (znikanie plików). GIT został przezemnie niedawno odkryty, wcześniej korzystałem z SVN-a oraz Mercurical. GIT działa naprawde dobrze i jest prosty w użyciu.