Po poprawnej autoryzacji dostałem dane dostępowe do konta i tu pierwszy szok. Już przed oczami przechodziły mi obrazy stawiania nowych portali, przenoszenia bloga oraz domen, a także udostępnienia kilku większych plików znajomym. Jednak to co zastałem okazało się totalną klapą. Panel administracyjny przypomina usługi hostingowe z których korzystałem 10 lat temu; archaiczny, niewygodny, z niewielką ilością opcji które są źle poustawiane lub ukryte w nieintuicyjnym miejscu. Najważniejszą bolączką był brak możliwości podpięcia zewnętrznych domen do systemu (np. z dnsów OVH) co skutecznie odstraszyło mnie od tego usługodawcy. Problemy są również z przesyłaniem plików, serwery często zrywają transfer co skutecznie utrudnia wgrywanie. Nie wiem jak działanie serwisów po udało im się mnie skutecznie odstraszyć. Po niecałych kilkunastu minutach stwierdziłem, że to nie dla mnie i postanowiłem już nie korzystać z ich usług.

Czy w związku z tym powinno się wystrzegać tej firmy? Myślę, że nie. Jeśli po upływie 2 lat firma nadal będzie oferować niskie ceny mogą być dobrą alternatywą dla niewymagających użytkowników, Ci którzy mają firmowe strony powinni uciekać jak najdalej. Brak polskiego wsparcia (dzwonisz do call center za granicą) oraz niska jakość usług (mało opcji, zrywanie połączeń) są wystarczającymi argumentami przeciw 1&1.

Za książką:

1. dobrze (choć mało wyczerpująco) opisane techniki oraz technologie J2EE,
2. proste oraz możliwie kompletne przykłady,
3. przystępny język oraz cena książki,

Przeciw książce:

1. tutorialowa forma książki,
2. niepotrzebne obszerne (zrzuty) opisy prostych czynności nie związanych bezpośrednio z technologią j2ee (integracja netbeans<=>tomcat, tworzenie projektu w netbeans),
3. źle sformatowane kody źródłowe (w ostatnich rozdziałach, gdzie tworzone są encje z zapytaniami nazwanymi kod zlewa się co utrudnia analizę),
4. za dużo o JSF jednak wciąż za mało by mieć mocne podstawy z tej technologii,
5. powtarzalność (w pewnym momencie mamy wrażenie, że autor się powtarza, szczególnie odnośnie przykładowego kodu)
6. słowo “Magikonwersja” (nie lubię takich tworów, za Potterem też nie przepadam)

Czy pomimo tylu minusów warto kupić książkę? Na to pytanie odpowiedzieć musi sobie każdy z osobna. Zapewne książka przydatna będzie zupełnym laikom którzy nie wiedzą nic odnośnie korporacyjnej javie, a chcieliby zacząć coś w niej robić.Również studenci znajdą w tej książce wiele interesujących informacji, a to za sprawą przystępnego treściwego języka oraz szeregu przykładów które dobrze przedstawiają omawiane tematy. Jeśli natomiast tworzyłeś już projekty w J2EE ta książka może jedynie nieznacznie uzupełnić Twoją wiedzę, czy jest sens ją kupować ocenisz sam.

W dniach 7-10 grudnia 2010 odbędzie się w Krakowie szkolenie z technologii Spring (w wersji 3.0). Prócz samego rdzenia tej technologii szkolenie obejmować będzie takie zagadnienia jak  Spring MVC, Spring AOP, Spring IOC, Spring JavaConfig, Spring Security, SpringSource Tool Suit i inne. Pełne zestawienie można pobrać w formacie pdf.
Dodatkowo rejestrując się do 4 września możliwe jest wykorzystanie kodu promocyjnego springup który skutkować będzie 15% rabatem. Jeśli na kurs wybieramy się z kolegą/koleżanką czeka nas rabat 10%, jeśli to będzie większa grupa, można liczyć na 20% rabat.  Po więcej informacji odsyłam na stronę kursu.

Kilka dni temu zakończyłem lekturę książki “Java. Efektywne programowanie. Wydanie II”. Z początku sceptycznie podchodziłem do wydania jako zbiór zasad które warto wykorzystać podczas pisania, no bo co nowego można napisać. Jednak już po kilku pierwszych tematach zdałem sobie sprawę, że książka warta jest każdej wydanej złotówki.
Autor w 78 tematach omawia zasady tworzenia obiektów, klas, metod, interfejsów, korzystania z typów ogólnych, wyliczeń, adnotacji, oraz zasady programowania, obsługi wyjątków czy też współbieżności i serializacji. Tematy opisane są zwięźle i klarownie, a tam gdzie to potrzebne autor przedstawia kod źródłowy z ew. modyfikacjami jakie należy nanieść by program był czytelny i co ważne działał poprawnie. Kod źródłowy jest dokładnie opisany, wraz z wytknięciem błędów, po czym autor wprowadza modyfikacje dokładnie je prezentując. Takie rozwiązanie pozwala łatwiej zrozumieć zamysł autora oraz lepiej przyswoić sobie rozwiązanie. Co ważne, książka była ciekawa (choć w kilku momentach nużąca) co pozwoliło mi w szybkim czasie przebrnąć przez wszystkie strony.

Niestety, nie ma rzeczy idealnych, w książce irytuje mnie częste wykorzystywanie słowa “klienty” (poprawne, ale mnie denerwuje, można by tu chyba użyć bardziej popularnego słowa “klienci”), czasami zdarza się, że bardziej rozbudowane zdania wydają się bez sensu, lub są trudne w zrozumieniu, nie wiem czy jest to problem tłumaczenia, czy może autor używa na tyle specyficznego języka, na szczęście zdarzyło się to dosłownie kilka razy.

Szczerze polecam.

Instalacja

Podczas instalowania korzystałem z 3 instrukcji oraz własnych eksperymentów. Wszystko składa się na kilka kroków (linki na końcu wpisu). W moim wypadku użyłem dysku zewnętrznego Seagate® Expansion™ o rozmiarze 1TB.

1) Aktualizujemy UBoot w urządzeniu korzystając z instrukcji pod linkiem nr 4.

2) Przygotowujemy instalator oraz instalujemy system korzystając z instrukcji pod adresem nr 2.

Uwagi:

a) W kroku Running the installer prócz stworzenia obrazu musiałem również stworzyć dodatkowych użytkowników, gdyż sam instalator pomimo użycia odpowiednich opcji nie zrobił tego

b) trzeba zapamiętać pod jakimi nazwami są nasze partycje, u mnie było to odpowiedni /dev/sda1 dla /boot oraz /dev/sda6 dla /

c) nie trzeba wysyłać stworzonych obrazów na zewnętrzny serwer.

d) Ponieważ jest to instalacja dla kart SD nie wykonujemy ostatniego kroku “Make the plug bootable“

3) Po zainstalowaniu systemu, przygotowaniu obrazów startowych oraz dodaniu użytkowników, zrestartowałem urządzenie i przeszedłem do Uboot-a gdzie trzeba było skonfigurować start systemu co jest opisane pod linkiem 3, ponieważ system miał startować z dysku usb należy najpierw znaleźć urządzenia, potem załadować obrazy, wskazać punkt montowania dla root a potem wystartować system, w moim wypadku polecenia ustawiające opcje startu wyglądały nastepująco:

setenv bootargs_console 'root=/dev/sda6 console=ttyS0,115200'
setenv bootcmd_usb 'usb start; ext2load usb 0:1 0x01100000 /uInitrd; ext2load usb 0:1 0x00800000 /uImage;'
setenv bootcmd 'setenv bootargs $(bootargs_console);run bootcmd_usb; bootm 0x00800000 0x01100000; reset'
saveenv

Uwaga!

Przed ostatnia linia zawiera polecenie reset które notabene powoduje zresetowanie/reboot całego urządzenia, jednak w tym wypadku polecenie to zostanie wykonane tylko i wyłącznie jeśli nie uda się boot-owanie systemu, jest to miejmy nadzieję tylko tymczasowe rozwiązanie do problemu który polega na losowym (co drugi raz) niewykrywaniu dysku USB więc jeśli dysk nie zostanie wykryty robimy reset i wykrywamy podobnie i tak w kółko aż zaskoczy.

4) Wykonujemy polecenie reset i startujemy system, powinno to potrwać ok minuty.

Co zauważyłem po kilku dniach używania:

1) Wiele osób narzeka na wysoką temperaturę swojego urządzenia (głównie wersja rozszerzona Server Plus), jakkolwiek nie mam termometru by to sprawdzić wygląda na to, że moje urządzenie jest wolne od wad, jest ciepłe, ale bez przesady, można dotykać, przytulać się, co kto lubi.

2) Instalacja na zewnętrznym dysku pomimo tego, że jest kłopotliwa drastycznie zwiększa wydajność całego systemu

3) Pozainstalowaniu Nginx-a, bazy PosgreSQL, mt-daap (strumieniowanie audio), mediatomb (serwer multimedialny dla mojej PS3), repozytorium git-a (+ gitosis) mam jeszcze dużo pamięci ram, wystarczy na tomcata i jeszcze nawet zostanie.

4) Port gigabitowy nie działa, podłączając kabel sieci 1Gb urządzenie się resetuje, na szczęście mam router 100Mb więc nie ma problemu

Zdjęcia nie będzie, bo GuruPlug wylądował pod łóżkiem i ciężko się do niego dostać.

Urządzenie GuruPlug JTag

Linki

1) Jeśli uda wam się coś zepsuć (programowo) w waszym GuruPlugu polecam stronę:
http://plugcomputer.org/plugwiki/index.php/Reflashing_images_on_the_GuruPlug

2) Instalacja Debiana na urządzeniu Guruplug (karta SD):
http://bzed.de/posts/2010/05/installing_debian_on_the_guruplug_server_plus/

3) Instalacja Debiana na urządzeniu Shevaplug (dysk USB):
http://www.cyrius.com/debian/kirkwood/sheevaplug/install.html

4) Aktualizacja Uboot
http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html

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);
%><br />
<nav>
 <ul>
 <li class="<% if(moduleName=="content"){ out.print("active"); } %>">
 <a href="<%= request.getContextPath() %>/content.html">
 <tag:message code="menu.content" />
 </a>
 </li>
 <li class="<% if(moduleName=="catalog"){ out.print("active"); } %>">
 <a href="<%= request.getContextPath() %>/catalog.html">
 <tag:message code="menu.catalog" />
 </a>
 <ul>
 <li class="<% if(moduleName=="categories"){ out.print("active"); } %>">
 <a href="<%= request.getContextPath() %>/catalog/categories.html">
 <tag:message code="menu.categories" />
 </a>
 </li>
 <li>
 <a href="<%= request.getContextPath() %>/catalog/books.html">
 <tag:message code="menu.books" />
 </a>
 </li>
 </ul>
 </li>
 <li class="<% if(moduleName=="order"){ out.print("active"); } %>">
 <a href="<%= request.getContextPath() %>/orders.html">
 <tag:message code="menu.orders" />
 </a>
 </li>
 <li class="<% if(moduleName=="client"){ out.print("active"); } %>">
 <a href="<%= request.getContextPath() %>/clients.html">
 <tag:message code="menu.clients" />
 </a>
 </li>
 <li>
 <a href="<%= request.getContextPath() %>/settings.html">
 <tag:message code="menu.settings" />
 </a>
 <ul>
 <li>
 <a href="<%= request.getContextPath() %>/settings/administrators.html">
 <tag:message code="menu.administrators" />
 </a>
 </li>
 </ul>
 </li>
 <li class="logout">
 <a href="<%= request.getContextPath() %>/wyloguj.html">
 <tag:message code="menu.logout" />
 </a>
 </li>
 </ul>
</nav>

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 Kenai.com. Adres bezpośredni do projektu: http://kenai.com/projects/summer-bookstore.
Dodatkowo zostało uruchomione repozytorium GIT dla wszystkich chętnych i dostępny jest pod adresem: git://kenai.com/summer-bookstore~books0re-source

Projekt umieszczony jest również w repozytorium Github pod adresem: http://github.com/darek/bookstore

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" %>
<html>
<head>

</head>
<body>
<c:if test="${isError eq true}">
 <div><tag:message code="login_error" /></div>
</c:if>
<div>
 <form action="<c:url value="/j_spring_security_check.html" />" method="POST">
 <div>
 <label for="login"><tag:message code="administrator.username"/></label>
 <input id="login" name="j_username"/>
 </div>
 <div>
 <label for="password"><tag:message code="administrator.password"/></label>
 <input type="password" id="password" name="j_password"/>
 </div>
 <div>
 <input type="submit"/>
 </div>
 </form>
</div>
</body>
</html>

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<GrantedAuthority> getAuthorities() {
 Set<GrantedAuthority> ga = new HashSet<GrantedAuthority>();
 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 Kenai.com. Adres bezpośredni do projektu: http://kenai.com/projects/summer-bookstore.
Dodatkowo zostało uruchomione repozytorium GIT dla wszystkich chętnych i dostępny jest pod adresem: git://kenai.com/summer-bookstore~books0re-source

Projekt umieszczony jest również w repozytorium Github pod adresem: http://github.com/darek/bookstore

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 Kenai.com. Adres bezpośredni do projektu: http://kenai.com/projects/summer-bookstore.
Dodatkowo zostało uruchomione repozytorium GIT dla wszystkich chętnych i dostępny jest pod adresem: git://kenai.com/summer-bookstore~books0re-source

1. Gdzie TOMCAT_HOME jest katalogiem głównym tomcata

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

Konfiguracja

Podstawowa konfiguracja obejmuje dwa pliki, najważniejszy web.xml oraz podstawowa konfiguracja spring-a i głównych servletów w pliku web-servlet.xml
Plik web.xml jest jak najbardziej zwyczajny, podana jest lokalizacja pliku web-servlet.xml, skonfigurowane zostały listenery, a także servlety wraz z mapowaniem.

web.xml:

<?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>

Dodatkowo wskazaliśmy plik który jest ładowany, gdy serwer otrzyma żądanie “/” (czyli strona startowa), w tym przypadku jest to załadowanie pliku redirect.jsp który przekieruje nas na stronę główną:

redirect.jsp:

<%@ 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

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

Do zobaczenia wkrótce.

Jak pobrać projekt

Projekt został umieszczony na serwerach Kenai.com. Adres bezpośredni do projektu: http://kenai.com/projects/summer-bookstore.
Dodatkowo zostało uruchomione repozytorium GIT dla wszystkich chętnych i dostępny jest pod adresem: git://kenai.com/summer-bookstore~books0re-source

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)