JSF - czyli jak ja to rozumiem...

JavaServer Faces - wstęp
Od jakiegoś czasu interesowałem się technologią JSF, nigdy jednak nie wystarczyło mi czasu i motywacji by zająć się ją na poważnie. Teraz się to zmieniło - mam już motywację (nowa praca :) ) - a czas chcę i muszę zorganizować, nic więc nie stoi na przeszkodzie by zacząć przekopywać internet, książki i dokumentacje w poszukiwaniu wartościowych informacji.

Postanowiłem, że będę zamieszczał tu rzeczy, które wydają mi się szczególnie ciekawe i godne zapamiętania. Wiem, że wielokrotnie mogę się mylić w rozumieniu nowych dla mnie zagadnień i mechanizmów.

Wobec tego zwracam się z prośbą do wszystkich odwiedzających tę stronę o uwagi krytyczne i wytykanie mi wszystkich zauważonych nieścisłości i pomyłek.

Java Server Faces - wariacje na temat... czyli pierwsze refleksje
Podczas kilkuletniego obcowania z J2EE wyrobiłem sobie zdanie, że tworzenie warstwy prezentacji jest słabym punktem całego procesu projektowania i implementacji tego typu aplikacji. Tworzenie interfejsów użytkownika zawsze kojarzyło mi się z czymś żmudnym i nie do końca zrozumiałym. Chociaż pojawiły się technologie wspomagające takie jak tagi JSTL, czy biblioteka Tiles to ciągle nie rozwiązywały one wszystkich problemów. Mam wrażenie że chociaż ewoluowały w kierunku ciągłych ulepszeń to jednak nie były rozwiązaniami kompleksowymi. Budowanie interfejsów ciągle wiązało się z uciążliwym iterowaniem list, wymagało mieszania logiki aplikacji z elementami prezentacyjnymi. Mam wrażenie że sytuację radykalnie zmieniło pojawienie się technologii JavaServer Faces.

Cechy JSF które wydają mi się godne zauważenia i wyróżniają ten framework spośród innych to:

• Przede wszystkim JSF jest standardem, który zapewne niedługo włączony zostanie do specyfikacji JEE.
  
• JSF jest frameworkiem komponentowym. Istnieje utrzymywany ścisły związek pomiędzy komponentami interfejsu użytkownika a komponentami zarządzanymi przez framework, których zadaniem jest dostarczanie danych i reagowaniem na zdarzenia generowane przez użytkownika.
  Wszystkie komponenty implementują ten sam interfejs, więc w wielu przypadkach obsługa ich zachowania odbywa się w sposób bardzo do siebie zbliżony. Skraca to czas potrzebny na opanowanie zasad posługiwania się technologią.
  
• Wszystkie elementy ułożone na stronie układają się w określoną hierarchię. Istnieje możliwość programowego wpływania na tą hierarchię.
  
• Tworzenie intefejsu użytkownika nie wymaga zrywania z obiektowym paradygmatem tworzenia aplikacji. Przy obsłudze zdarzeń ciągle operujemy na obiektach, framework zdejmuje z nas obowiązek przesyłania parametrów w postaci tekstowej.
  
• JSF wprowadza znany z aplikacji desktopowych model obsługi zdarzeń.
  
• Mechanizmy frameworka dbają o to, by zapamiętywać stan komponentu pomiędzy różnymi żądaniami nadsyłanymi przez klienta.
• Architektura JSF jest oparta o dobrze znane i wielokrotnie sprawdzone w praktyce wzorce projektowe takie jak: MVC, Observer, Composite.
  
• Konfiguracja jest jasna, zgromadzona w plikach xml.
• Osadzanie komponentów na stronie odbywa się w sposób deklaratywny, nie wymaga mieszania logiki z elementami odpowiedzialnymi za prezentację.
• Framework dostarcza pokaźną bibliotekę komponentów interfejsu użytkownika renderujące określone struktury danych.
  
• Wraz z frameworkiem dostarczane są obiekty pomocnicze takie jak renderery, walidatory poprawności danych.
• Framework dostarcza mechanizmów przetwarzania wielokrokowych formularzy, walidację danych, konwersję typów, obsługę zdarzeń,.
  

Różnica pomiędzy manage bean i backing bean
Technologia JSF wprowadza kilka nowych pojęć - te, których zrozumienie sprawiło mi trochę kłopotu to "managed bean" i "backing bean".

Na początek "backing bean". Jest to komponent, który w architekturze MVC, o którą oparty jest JSF ma pełnić rolę warstwy modelu i stanowić punkt styku pomiędzy warstwą prezentacji i biznesową. Ma on delegować żądania klienta do niższych warstw aplikacji. Jest on skojarzony z odpowiadającym mu komponentem UI (User Interface) używanym na stronie. Definiuje skojarzone z nim właściwości i metody stanowiące o logice jego zachowania. Dzięki nim występuje całkowita separacja logiki od definicji komponentu interfejsu użytkownika.

Czym wobec tego jest "managed bean" ?

Różnica pomiędzy nimi jest bardzo subtelna, podjąłem nawet próbę jej odkrycia. Niestety nie znalazłem nic co by całkowicie mnie przekonało, ale na jednym z forów trafiłem na ciekawą dyskusję, a niewątpliwie jej najciekawsze zdanie brzmi:

"managed beans are instances of backing beans which are made available to the JSF pages by defining them in the faces-config.xml"

Myślę że na chwilę obecną, należy przyjąć ją za całkiem rozsądną...

Etapy przetwarzania żądania przez framework JSF
W przetwarzaniu żądania można wyróżnić kilka faz:

• Restore View - etap tworzenia drzewa komponentów skojarzonych z żądanym zasobem (stroną). W przypadku gdy w obrębie danej sesji użytkownika drzewo było już tworzone, framework w tej fazie odtwarza pierwotny stan komponentów.
  
• Apply Request Value - w przypadku gdy drzewo zostało odtworzone, w tym etapie następuje uaktualnienie wartości komponentów. Następuje sprawdzenie czy w obiekcie żądania (request) nie znajdują się nowsze wartości elementów komponentu UI, jeśli istnieją, zostają one uaktualnione.
  
• Process Validations - w tej fazie przetwarzania uruchomione zostają validatory poprawności skojarzone z elementami komponentu UI. Sprawdzana jest kompletność i poprawność wartości pól.
  
• Update Model Values - w tym etapie przetwarzania komponent interfejsu użytkownika sprawdza i uwspólnia model danych ze skojarzonym z nim beanem.
  
• Invoke Application - w tej fazie obsługiwane są wszystkie skolejkowane zdarzenia.
  
• Render Response - po uwzględnieniu wszystkich zmian jakie zaszły przy przetwarzaniu żądania tworzone jest nowe drzewo komponentów i trwale jest ono kojarzone z określoną stroną jsp.
  

ToyStore - sklep z zabawkami ( Sitemesh, JSF, Spring, Hibernate, Oracle Express )- CZĘŚĆ I I- WARSTWA WEB

Zapraszam do zapoznania się z częścią I artykułu :
ToyStore - sklep z zabawkami ( Sitemesh, JSF, Spring, Hibernate, Oracle Express )- CZĘŚĆ I - warstwa danych i biznesowa

A więc do dwóch warstw naszej aplikacji teraz podejmę próbę dopracowania trzeciej - umożliwiającej dostęp do aplikacji przy pomocy przeglądarki WWW. Jako że ostatnio przechodzę okres zauroczenia frameworkiem JSF, wybór technologii realizacji zadania nie był trudny... a wiec do rzeczy...

Konfiguracja serwletu FacesServlet i webowego kontekstu aplikacji

Framework JSF jest oparty na ogólnie znanym wzorcu projektowym MVC (Model View Controller ) nic więc dziwnego, że najważniejszym elementem jego konfiguracji jest właściwe zdefiniowanie parametrów Serwletu Rozdzielającego (Servlet Dispatcher) . W przypadku JSF nosi on nazwę FacesServlet. Jego konfiguracja odbywa się w deskryptorze rozmieszczenia - pliku /WEB-INF/web.xml.

Sama modyfikacja pliku jest bardzo prosta sprowadza się ona do kilku rzeczy:

Po pierwsze należy zdefiniować sam serwlet. Robi się to przy pomocy następującego kodu:

<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

Ponieważ nasza aplikacja ma mieć możliwość korzystania z obiektów stworzonych przez Springa należy zdefiniować jej kontekst springa, przez definicję odpowiedniego listenera:

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

Ostatnim krokiem będzie zdefiniowanie filtra, który wszystkie żądania zakończone przyrostkiem *.faces będzie przekierowywał do serwletu Faces Servlet. Wygląda on następująco:

<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.faces</url-pattern>
</servlet-mapping>

Nasz serwlet jest już gotowy do pracy... teraz czas na stworzenie pierwszego komponentu JSF.

Pierwszy scenariusz - wyświetlenie listy kategorii
Na początek chciałbym wyświetlić listę kategorii produktów, które są w bazie. Chciałbym, aby była ona prezentowana w postaci tabelki, z której to możnaby przejść do edycji kategorii, usunąć ją, dodać nową, a także obejrzeć jakie produkty do niej należą.

Wykorzystanie technologii JSF implikuje, że do realizacji tego scenariusza będziemy potrzebowali definicji dwóch rzeczy, a mianowicie:

• strony na której zdefiniowany będzie UI kompotent odpowiedzialny za renderowanie tabelki
  
• beana ( backing beana), który w architekturze MVC umiejscowiony będzie w warstwie modelu i stanowić będzie zaplecze dla komponentu UI. Jego zadaniem będzie dostarczenie danych potrzebnych do wypełnienia tabelki, jak również metod stanowiących o logice działania (więcej o beanach napisałem w artykule JSF- czyli jak ja to rozumiem...).
  

Nasz pierwszy backing bean - CategoryListUI
Pierwszym krokiem, który należy wykonać jest zdefiniowanie obiektu - beana, który zasili naszą tabelkę w dane i dostarczy obsługującej ją logiki. W terminologii JSF bean taki nazywa się "backing bean".

A więc umiejscawiam go w pakiecie mw.toystore.web.ui i nadaję nazw CategoryListUI.

Nasz bean będzie korzystał z kontekstu springowego i za jego pośrednictwem uzyska referencje do interfejsu biznesowego IProductManager. Aby obiekt ten został prawidłowo zaincjalizowany przy pomocy mechanizmu IoC w klasie backing beana należy zdefiniować własność tego typu, oraz metody dostępowe (setter i getter). Stosowny fragment kodu wygląda następująco:

.......
private IProductManager productManager;

public IProductManager getProductManager() {
return productManager;
}

public void setProductManager(IProductManager productManager) {
this.productManager = productManager;
}
.......

Teraz, gdy nasz komponent potrafi już sięgnąć do warstwy biznesowej można stworzyć metodę, za której pośrednictwem komponent interfejsu użytkownika (UI) leżący na stronie i skojarzony z naszym beanem uzyska dostęp do listy obiektów kategorii. Niech nazywa się ona getCategoryList(). Jej konstrukcja będzie bardzo prosta, bo ograniczy się tylko do wywołania metody z obiektu interfejsu biznesowego i zwrócenia na zewnątrz pobranej z niższych warstw aplikacji kolekcji obiektów kategorii. Nasza metoda wygląda następująco:

public List getCategories(){
return this.productManager.getCategoryList();
}

W tym momencie nasz bean potrafi zaserwować listę kategorii, posiada więc minimalną funkcjonalność. Dzięki niemu komponent interfejsu użytkownika będzie w stanie uzyskać kolekcję obiektów reprezentujących różne kategorie.

Zanim jakikolwiek komponent interfejsu użytkownika skorzysta z naszego beana musi zostać wykonana stosowna konfiguracja, która dokonuje się przez dokonanie modyfikacji w pliku /WEB-INF/faces-config.xml. Przyjrzyjmy się im trochę dokładniej.

Propagowanie beana jako Managed Bean

Przyszedł czas na integrację naszego beana z frameworkiem JSF. Odbywa się ona przez dokonanie odpowiednich wpisów w pliku konfiguracyjnym /WEB-INF/faces-config.xml.

Myślę, że można powiedzieć, że każdy backing bean, którego opiszemy w tym pliku nabywa kilka nowych cech. Przede wszystkim, nadana mu tutaj logiczna nazwa jest widoczna dla wszystkich komponentów interfejsu użytkownika. Mogą się do niego odwoływać i na podstawie uzyskanych od niego informacji renderować odpowiednie elementy interfejsu użytkownika.
Cyklem życia takiego beana zarządza już sam framework. W żadnym miejscu nie ma konieczności martwienia się o jego stworzenie i poprawną inicjalizację. Zadba o to framework. Być może dlatego po propagacji, beany uzyskują nową nazwę - managed beans.

Ale po kolei. Przyjrzyjmy się kolejnym elementom naszego pliku /WEB-INF/faces-config.xml.

Cała konfiguracja objęta jest tagami <faces-config> </faces-config>.

Przed definicją beana znajduje się wpis konfiguracyjny o specjalnym znaczeniu. Mianowicie powoduje on, że framework JSF uzyskuje dostęp także do kontekstu springowego (temat integracji frameworków Spring i JSF opisałem w artykule "Próba połączenia JSF i Spring..." ). Dzięki temu do naszego managed beana możliwe jest wstrzyknięcie obiektów zarządzanych przez kontener IoC (a więc np. naszego interfejsu biznesowego IProductManager). Stosowny fragment pliku wygląda następująco:

<application>
<variable-resolver>org.springframework.web.jsf.DelegatingVariableResolver</variable-resolver>
</application>

Definicja samego managed beana wygląda następująco:

<managed-bean>
<managed-bean-name>categoryListUI</managed-bean-name>
<managed-bean-class>mw.toystore.web.ui.CategoryListUI</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>productManager</property-name>
<value>#{productManager}</value>
</managed-property>
</managed-bean>

Powyższe wpisy powodują że stworzony zostanie managed bean o identyfikatorze categoryListUI (pod tą nazwą będzie on widzialny dla komponentów UI). Jako klasę beana wskazałem omawianą wcześniej klasę mw.toystore.web.ui.CategoryListUI . Kolejna właściwość określa, że bean będzie przesyłany w obiekcie żądania.
Na uwagę zasługuje sekcja:

<managed-property>
<property-name>productManager</property-name>
<value>#{productManager}</value>
</managed-property>

Jak pamiętamy, klasa naszego beana ma zdefiniowaną właściwość o nazwie propertyManager, oraz dwie metody dostępowe do niej. W tym momencie zostają one wykorzystane przez framework do ich inicjalizacji. W kontekście Springa odszukany zostaje obiekt o logicznej nazwie productManager ( id="productManager"), a następnie jego wartość zostaje wstrzyknięta do naszego beana za pomocą wywołania metody setProductManager().

Nasz bean został spropagowany, jest dostępny dla stron JSP, teraz możemy przejść do tworzenia strony JSP, na której umieszczony zostanie komponent interfejsu użytkownika, który skorzysta z danych zwróconych z naszego beana i zrenderuje dla nas stosowną dla nich tabelę.

Strona z komponentem UI - categoryList.jsp

Na początek w katalogu głównym naszej aplikacji zakładam plik cateogoryList.jsp. Chciałbym aby komponent JSF umieszczony na niej wykorzystywał zdefiniowany wcześniej managed bean i wyświetlał nazwy wszystkich kategorii. A więc potrzebna będzie tabela.

Z początku nie wiedziałem jak się zabrać za jej tworzenie ale z pomocą przyszło google i artykuł Jacka Laskowskiego poświęcony tabelom w JSF. Znalazłem tam sczególowy opis znacznika <h:dataTable>

Aby uniknąć problemów z wyświetlaniem polskich znaczków rozpoczynam od ustawienia kodowania na utf-8:

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

Na początek definicja bibliotek znaczników związanych z wykorzystaniem elementów JSF:

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>

Ponieważ będzie ona potrzebna na wszystkich stronach wykorzystujących komponenty JSF, wydzieliłem ją do pliku /WEB-INF/jsp/include.jsp i włączam do moich stron za pomocą dyrektywy include:

<%@ include file="/WEB-INF/jsp/include.jsp"%>

Od tej chwili do elementów JSF będę mógł odwołać się przy pomocy schematu "przedrostek_tagliba:nazwa_elementu", gdzie jako przedrostek wystąpi jeden z dwóch zdefiniowanych powyżej (f dla tagów z jsf-core i h dla tagów z jsf-html).

A więc od początku. Na szczycie hierarchii elementów JSF umieszczonych na stronie zawsze musi znaleźć się element f:view>/f:view>. Dopiero w jego wnętrzu mogą zostać umieszczone inne tagi. Definicja naszej najprostszej tabelki będzie wyglądała następująco:

<h:dataTable value="#{categoryListUI.categories}" var="category" border="1" styleClass="listtab"> <h:column> <f:facet name="header"> <f:verbatim>Name</f:verbatim> </f:facet> <h:outputText value="#{category.name}" /> </h:column> </h:dataTable>

Kluczowe znaczenie mają dwa atrybuty ustawiane na samym początku a mianowicie:

• value - powoduje że lista obiektów, które mają zostać zaprezentowane w tabelce pobrana zostanie z obiektu o nazwie catgoryListUI (nazwa logiczna z pliku faces-config.xml), na podstawie jego własności categories . Tu należałoby wyjaśnić jedną rzecz. Mianowicie bean ten nie musi mieć własności categories, wystarczy, że tak jak w naszym przypadku będzie miał zdefiniowaną metodę getCategories().
• var - jest to nazwa logiczna obiektu pobranego z kolekcji przy pojedynczej iteracji

Atrybut "styleClass" powoduje że zrenderowana tabelka w kodzie wynikowym przypisana będzie do klasy CSS o nazwie "listtab" (klasę tą zdefiniujemy później, przy itegracji z SiteMeshem).

Definicja pojedynczej kolumny tabeli następuje we wnętrzu tagu <h:column> </h:column>. Nie musimy oprogramowywać samej iteracji - wystarczy definicja nagłówka kolumny (<f:facet name="header"></f:facet name="header">) i wskazania pola z którego przy kolejnej iteracji powinna zostać wyciągnięta wartość wierszowa (<h:outputText value="#{category.name}" />).

A więc definicja naszej najprostszej tabeli wygląda na kompletną. Czas na uruchomienie serwera , a potem umieszczeniem na nim naszej aplikacji.

Po wpisaniu adresu: http://localhost:3333/ToyStoreJSFApp/categoryList.faces

Na ekranie pojawiła się tabelka:

A więc wygląda na to że pierwszy i kluczowy przypadek użycia naszej aplikacji został zrealizowany. Wyświetla ona tabelkę z kategoriami produktów.

ToyStore - sklep z zabawkami ( Sitemesh, JSF, Spring, Hibernate, Oracle Express )- CZĘŚĆ I - warstwa danych i biznesowa

Wstęp
Już pierwszy kontakt z frameworkiem JSF, jaki zyskałem po zrobieniu pierwszej aplikacji (spring+jsf) przekonał mnie, że obrany przeze mnie kierunek jest jak najbardziej właściwy. JSF wydaje się być tym czego od dawna już szukałem - sam framework i biblioteka komponentów, wprowadzają rewolucję do projektowania interfejsów webowych. Koniec z JSTL i iterowaniem po kolekcjach :))).

Zachęcony pierwszym sukcesem postanowiłem przystąpić do realizacji trochę bardziej złożonego projektu.

Według moich założeń za warstwę prezentacji bezpośrednio odpowiadałby JSF udekorowany przy pomocy SiteMesha, do tworzenia obiektów warstwy biznesowej i dao chciałbym użyć Springa, jako ORMa użyłbym Hibernate. Jako bazę relacyjną wybrałem Oracle Express. Dodatkowo Spring wystąpiłby w roli frameworka integracyjnego i głównego "wstrzykiwacza" zależności ;)). Wszystko składaneby było do kupy Antem i deployowane na JBoss-a 4.0.5.

Założenia projektu:
Cała aplikacja realizowałaby kila przypadków użycia z zakresu prezentacji i zarządzania produktów przypisanych do określonych kategorii.


No cóż... moja aplikacja swą złożonością na pewno nikogo nie powali na kolana, ale do prezentacji możliwości frameworków wydaje się całkiem ok.

Środowisko projektowe:

Jak większość moich projektów, tak i ten powstanie w Eclipse dozbrojonym przez Hibernate Tools, WTP i JBoss IDE. Projekt będzie się nazywał MWToyStoreJSFApp i będzie miał następującą strukturę:


Kolejny krok to import i kompletowanie wszystkich potrzebnych bibliotek. Ich lista w końcu ustaliła się na:
********************
antlr-2.7.6.jar
asm-attrs.jar,asm.jar
glib-2.1.3.jar, cglib-nodep-2.1_3.jar
commons-beanutils.jar, commons-collections-2.1.1.jar, commons-collections.jar, commons-digester.jar, commons-logging-1.0.4.jar, commons-logging.jar
dom4j-1.6.1.jar
ehcache-1.2.jar
hibernate3.jar
html_basic.tld
jdbc2_0-stdext.jar
jsf-api.jar, jsf-impl.jar
jsf_core.tld, jstl.jar
jta.jar
log4j-1.2.11.jar
ojdbc14.jar
servlet-api.jar
sitemesh-2.3.jar, sitemesh-decorator.tld, sitemesh-page.tld
spring-aspects.jar, spring-mock.jar, spring.jar, standard.jar
********************

Pierwsze planowanie

I w ten oto sposób zrobiłem pierwszy krok - powstał zaczątek mojego projektu. Nadszedł czas tworzenia koncepcji. Na chwilę obecną skupię się na zaplanowanie warstwy danych i biznesowej, JSF ciągle stanowi dla mnie zagadkę, więc tworzeniem modelu i implementacją warstwy web zajmę się w późniejszym etapie realizacji.

Na początek stworzyłem iście imponujący model dziedziny:


Zarządzanie obiektami encji odbywać się będzie za pośrednictwem warstwy danych, na którą w mojej aplikacji złoży się niewielki interfejs IProductManagerDao i implementująca go klasa dostępowa ProductManagerDaoHibernate.


Pomiędzy warstwą danych a web wprowadzę biznesową warstwę pośredniczącą. Tak samo jak w warstwie niższej złoży się na nią jeden interfejs metod biznesowych IProductManager i implementująca go klasa ProductManager.


Tak jak wspomniałem już wcześniej warstwę web muszę potraktować w sposób indywidualny, dlatego na tę chwilę wstrzymam się z projektowaniem i wreszcie zacznę implementację :))).

Przygotowanie bazy danych:
Na samym początku na podstawie modelu dziedziny piszę skrypt inicjalizacji bazy danych:

CREATE TABLE CATEGORY(ID NUMBER NOT NULL PRIMARY KEY,
DESCRIPTION VARCHAR(500),
NAME VARCHAR(50),
LOGO VARCHAR(10));

CREATE TABLE PRODUCT(ID INT NOT NULL PRIMARY KEY,
CATID INT NOT NULL,
DESCRIPTION VARCHAR(500),
PRICE NUMBER(10),
NAME VARCHAR2(50),
LOGO VARCHAR2(50),
CONSTRAINT fk_products_in_cat FOREIGN KEY (CATID)REFERENCES CATEGORY (ID)
);

INSERT INTO CATEGORY(ID,NAME,DESCRIPTION) VALUES(1,'Ksiazki','Wszystkie ksiazki');
INSERT INTO CATEGORY(ID,NAME,DESCRIPTION) VALUES(2,'Czasopisma','Dzienniki, miesięczniki');
INSERT INTO CATEGORY(ID,NAME,DESCRIPTION) VALUES(3,'Broszury','Przewodniki turystyczne');

INSERT INTO PRODUCT(ID,NAME,CATID,DESCRIPTION,PRICE) VALUES(1,'Winnetou',1,'Wszystkie trzy tomy',10);
INSERT INTO PRODUCT(ID,NAME,CATID,DESCRIPTION,PRICE) VALUES(2,'Tomek Wilmowski',1,'Wszystkie części powieści przygodowej',50);

INSERT INTO PRODUCT(ID,NAME,CATID,DESCRIPTION,PRICE) VALUES(3,'Motor',2,'Miesięcznik',10);
INSERT INTO PRODUCT(ID,NAME,CATID,DESCRIPTION,PRICE) VALUES(4,'Piłka Nożna',2,'Miesięcznik',10);
INSERT INTO PRODUCT(ID,NAME,CATID,DESCRIPTION,PRICE) VALUES(5,'Mój Pies',2,'Miesięcznik',10);

INSERT INTO PRODUCT(ID,NAME,CATID,DESCRIPTION,PRICE) VALUES(6,'Przewodnik turystyczny',3,'Broszura',10);

Jeszcze tylko kilka ustawień w moim build. xml, uruchomienie, radość z poprawnego wykonania się skryptu i oto moje tabele znalazły się w bazie danych. Uff.. a więc coś się ruszyło. :).

Tworzenie mapowań ORM (Category.hbm.xml i Product.hbm.xml) obiektów domeny
Mapowania te stworzyłem przy pomocy Hibernate Tools. Na początek, posługując się wizzardem(File->New->Project->Hibernate->Other->Hibernate Configuration File) zdefiniowałem dane potrzebne do ustanowienia połączenie do bazy danych. W wyniku jego działania otrzymałem plik konfiguracyjny hibernate.cfg.xml . Ma on następującą postać:

<?xml version="1.0" encoding="UTF-8"?>
<!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.connection.driver_class">oracle.jdbc.driver.OracleDriver
</property>
<property name="hibernate.connection.password">abc</property>
<property name="hibernate.connection.url">jdbc:oracle:thin:@localhost:1521:XE</property>
<property name="hibernate.connection.username">wojcikm</property>
<property name="hibernate.default_schema">WOJCIKM</property>
<property name="hibernate.dialect">org.hibernate.dialect.Oracle9Dialect</property>
</session-factory>
</hibernate-configuration>

Po stworzniu pliku konfiguracyjnego przełączam perspektywe na "Hibernate Console" (Window->Open Perspective->Hibernate Console) , i w jej obrębie otwaram sobie widok Hibernate Configurations (Window->Show View->Hibernate Configurations) .
Teraz w jego obrębie, klikam na prawy przycisk myszy i po otwarciu menu kontekstowego wybieram opcję Add Configuration. Otwiera się wizzard, w którym podaję dane konfiguracji:

Kluczowym krokiem jest podanie "Configuration file" - tu należy wskazać wygenerowany wcześnej plik "hibernate.cfg.xml" .

Po poprawnym zdefiniowaniu połączenia plugin pozwala na przeglądanie obiektów bazy danych.

Po rozwinięciu węzła "Database" powinny pojawić się obiekty DB.

UWAGA!!!
Wiele czasu i nerwów straciłem na dociekanie przyczyn wystąpienia pewnego błędu. Otóż przy próbie rozwinięcia gałązki nie pojawiało się nic.

Okazało się że przyczyna leży w pliku hibernate.cfg.xml, a dokładniej w jego opcji:

<property name="hibernate.default_schema">WOJCIKM</property>

Z niewiadomych mi przyczyn jej wartość musi zostać napisana WIELKIMI LITERAMI.

Po zdefiniowaniu "Console Configuration" czas przystąpić do wygenerowania plików mapowań Hibernate. W tym celu przez wybranie opcji z belki narzędziowej uruchamiam kolejny wizzard:

Po otwarciu się okna neleży wypełnić opcje:
(zakładka Main)

• Console Confiugration - z listy należy wybrać nazwę ostatnio zdefiniowanej konfiguracji
• Output Directory - katalog do którego wygenerowane zostaną pliki
• Package - pakiet do którego należeć będą pliki (mw.toystore.domain)

(zakładka Exporters)

• Hibernate XML Mappings (.hbm.xml)

Po wciśnięciu przycisku Run do wskazanego katalogu zostaną wygenerowane pliki mapowań.

Plugin tworzy oddzielny plik dla każdej encji db, ja łączę je w jeden duży plik HibernateMapping.hbm.xml i umieszczam w katalogu WEB-INF/context . Plik ten ma następującą postać. Należy pamiętać, że mapowania w tym pliku muszą być całkowicie zgodne z właściwościami obiektów domeny (mw.toystore.domain.*). Obiekty domenowe mogą również zostać wygenerowane przez plugin - jednak ja wolałem zrobić to ręcznie.

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<class name="mw.toystore.domain.Category" table="CATEGORY">
<id name="id" column="ID">
<generator class="sequence">
<param name="sequence">WOJCIKM.CATEGORY_ID_SEQ</param>
</generator>
</id>
<property name="description" type="string">
<column name="DESCRIPTION" length="500" />
</property>
<property name="name" type="string">
<column name="NAME" length="50" />
</property>
<property name="logo" type="string">
<column name="LOGO" length="10" />
</property>
<set name="products" inverse="true">
<key>
<column name="CATID" precision="22" scale="0" not-null="true" />
</key>
<one-to-many class="mw.toystore.domain.Product" />
</set>
</class>


<class name="mw.toystore.domain.Product" table="PRODUCT">
<id name="id" column="ID">
<generator class="sequence">
<param name="sequence">WOJCIKM.PRODUCT_ID_SEQ</param>
</generator>
</id>
<many-to-one name="category" class="mw.toystore.domain.Category" fetch="select">
<column name="CATID" precision="22" scale="0" not-null="true" />
</many-to-one>
<property name="description" type="string">
<column name="DESCRIPTION" length="500" />
</property>
<property name="price" type="java.lang.Long">
<column name="PRICE" precision="10" scale="0" />
</property>
<property name="name" type="string">
<column name="NAME" length="50" />
</property>
<property name="logo" type="string">
<column name="LOGO" length="50" />
</property>
</class>
</hibernate-mapping>

Kod obiektów domeny zgodny z powyższym mapowaniem wygląda następująco:




Realizacja warstwy biznesowej - dostępu do danych (dao)
Kod metod klasy realizującej operacje na obiektach domeny - mw.toystore.db.dao.ProductManagerDaoHibernate (klasa ta implementuje interfejs mw.toystore.db.dao.IProductManagerDao) ma ma następującą postać (kod niekompletny):

package mw.toystore.db.dao;

import mw.toystore.domain.Product;
import mw.toystore.domain.Category;
import java.util.*;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.springframework.dao.DataAccessException;
import org.springframework.orm.hibernate3.support.HibernateDaoSupport;
import org.hibernate.*;

/**
* @created 18-sie-2006 11:49:42
* @version 1.0
*/
public class ProductManagerDaoHibernate extends HibernateDaoSupport implements
IProductManagerDao {

private Log logger = LogFactory.getLog(getClass());
public List getCategoryList() {
return getHibernateTemplate().find("from Category");
}

public Category getCategoryById(int id) {
return (Category) getHibernateTemplate().get(Category.class,
new Integer(id));
}

public void saveCategory(Category cat) {
getHibernateTemplate().saveOrUpdate(cat);
}

public void removeCategory(Category cat) {
Category c=this.getCategoryById(cat.getId().intValue());
this.getHibernateTemplate().delete(c);
}
....
}


Zadaniem metod których kod zamieściłem powyżej jest manipulacja obiektami domenowymi. Klasa ta jest wydziedziczona z klasy HibernateDaoSupport pochodzącej ze Springa. Cecha ta powoduje że w kodzie metod można wykorzystywać springowe wsparcie dla frameworka Hibernate. Powoduje to daleko idące uproszczenie kodu metod. Nice !!!! :))


Realizacja warstwy biznesowej
Tak jak wspominałem wcześniej logika biznesowa jest realizowana przez klasę mw.toystore.ProductManager która implementuje interfejs mw.toystore.IProductManager.
Fragment jej kodu wygląda następująco:

public class ProductManager implements IProductManager {

private Log logger = LogFactory.getLog(getClass());
private IProductManagerDao productManager;

public Product getProductById(int id){
return productManager.getProductById(id);
}

public void saveProduct(Product p){
this.productManager.saveProduct(p);
}
...

}

W moim przypadku znaczenie tej warstwy jest niewielkie. Kod metod odwołuje się do adekwatnych metod z warstwy Dao za pośrednictwem interfejsu IProductManagerDao.

Nie muszę martwić się o prawidłową jego inicjalizacje. O to zadba framework IoC - czyli Spring(ale o tym za chwilę ) :).

Konfiguracja kontekstu springowego
Kontrolę nad poprawną inicjalizacją obiektów sprawuje kontroler IoC (Inversion of Control), czyli w przypadku mojej aplikacji framework Spring. Aby mógł od dobrze wykonywać swoją pracę musi on zostać gruntownie poinformowany o wszystkich obiektach aplikacji i wzajemnych relacjach, które pomiędzy nimi zachodzą.

Pliki konfiguracyjne kontenera IoC umieściłem w podkatalogu /WEB-INF/contex. Przy inicjalizacji całej aplikacji automatycznie wczytywany jest plik /WEB-INF/applicationContext.xml (nazwa musi być ustandaryzowana !!!!) w nim to zawarte są odwołania do kilku plików z podkatalogu /WEB-INF/context.

Wymagane jest istnienie tylko pliku /WEB-INF/applicationContext.xml, mogłyby znaleźć się tu wszystkie mapowania jednak w celu łatwiejszego zapanowania nad konfiguracją podzieliłem ją na pliki:

• /WEB-INF/applicationContext.xml
• /WEB-INF/context/springapp-servlet-datasources.xml
  
• /WEB-INF/context/springapp-servlet-db.xml
  
• /WEB-INF/context/HibernateMapping.hbm.xml
  
• /WEB-INF/context/springapp-servlet-bus.xml
  

Plik applicationContext.xml

Plik springapp-servlet-datasources.xml

<!--
*********************************************************
************* Warstwa konfiguracji źródeł danych
*********************************************************
-->
<beans>
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName">
<value>oracle.jdbc.driver.OracleDriver</value>
</property>
<property name="url">
<value>jdbc:oracle:thin:@localhost:1521:XE</value>
</property>
<property name="username">
<value>wojcikm</value>
</property>
<property name="password">
<value>abc</value>
</property>
</bean>
</beans>

W pliku tym jest zdefiniowany tylko jeden bean "dataSource" - w jego właściwościach podane są podstawowe informacje, które pozwalają na nawiązanie połączenia z bazą danych.

Plik springapp-servlet-db.xml
Spring oferuje szereg obiektów wspomagających realizację odwzorowań obiektowo relacyjnych. Aby mogły być one poprawnie zainicjalizowane musi zostać zdefinowanych szereg parametrów.

<!--
*********************************************************
************* Warstwa odwzorowań obiektowo-relacyjnych
*********************************************************
-->
<beans>
<bean id="sessionFactory"
class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
<property name="dataSource">
<ref bean="dataSource" />
</property>
<property name="mappingLocations">
<value>/WEB-INF/context/HibernateMapping.hbm.xml</value>
</property>
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">
org.hibernate.dialect.Oracle9Dialect
</prop>
</props>
</property>
</bean>

<bean id="productManagerDaoHibernate" class="mw.toystore.db.dao.ProductManagerDaoHibernate">
<property name="sessionFactory">
<ref bean="sessionFactory" />
</property>
</bean>
</beans>

Następujący fragment pliku:

<property name="dataSource">
<ref bean="dataSource" />
</property>

stanowi sztandarowy przykład kofiguracji wstrzyknięcia IoC. Bean "sessionFactory" (którego definicji akurat nie musimy tworzyć bo pochodzi ze standardowych bibliotek springowych) posiada właściwość (property) o nazwie "dataSource" (w jego kodzie MUSZĄ zostać zdefiniowane metody setDataSource() i getDataSource() - zgodnie ze specyfikacją JavaBean).
Jako wartość podawana jest referencja do innego beana- a mianowicie omawianego wcześniej, zdefiniowanego w pliku springapp-servlet-datasources.xml beana "dataSource" .
Na podstawie omawianych wpisów konfiguracyjnych kontener IoC, stworzy najpierw beana "dataSource", a następnie beana "sessionFactory". Następnie na obiekcie "sessionFactory" wywołana będzie metoda "setDataSource()" a jako jej parametr przekazany zostanie obiekt "dataSource". Od tego momentu programista może w dowolny sposób używać obiektu "sessionFactory" - wartość jego właściwości dataSource nie jest już równa null - została ona zainicjalizowana.

Należy zwrócić szczególną uwagę na ustawienie właściwej wartości dla property "mappingLocations"

<property name="mappingLocations">
<value>/WEB-INF/context/HibernateMapping.hbm.xml</value>
</property>

Za jej pośrednictwem informujemy Springa gdzie znajdują się wygenerowane przez nas wcześniej mapowania obiektowo relacyjne dla istniejących obiektów dziedzinowych.

Plik springapp-servlet-bus.xml
definicja zależności pomiędzy obiektami warstwy biznesowej.
<!--
*************************************************
************* Warstwa usług biznesowych ********
*************************************************
-->
<beans>
<bean id="productManager" class="mw.toystore.bus.ProductManager">
<property name="productManager">
<ref bean="productManagerDaoHibernate" />
</property>
</bean>
</beans>

Beany zdefiniowane w tym pliku odpowiadają za realizację logiki biznesowej. Tworzony jest bean "productManager" będący obiektem klasy "mw.toystore.bus.ProductManager". Bean ten ma zdefiniowaną właściwość "productManager" (i odpowiednie metody dostępowe). Właściwość ta zostanie zainicjalizowana obiektem "productManagerDaoHibernate" , który zdefiniowany został już wcześcniej. Od tej pory programiści którzy będą wykorzystywać obiekt "productManager" będą mogli odnoscić się niżej, do metod interfejsu DAO implementowanego przez beana "productManagerDaoHibernate".
W kodzie klasy deklaracja właściwości i jej metod dostępowych wygląda następująco (należy zwrócić uwagę na fakt, że do poprawnego wstrzyknięcia przez Springa własności "productManager" konieczne są wszystkie elementy przedstawione poniżej ):

public class ProductManager implements IProductManager {
private IProductManagerDao productManager;

public IProductManagerDao getProductManager(){
return productManager;
}

public void setProductManager(IProductManagerDao newVal){
productManager = newVal;
}
......
}


Plik HibernateMapping.hbm.xml
Nie jest to plik bezpośrednio związany ze Springiem (choć pośrednio na pewno tak) - znajduje się w nim mapowania obiektów bazy danych na obiekty dziedziny. Struktura, rola i zawartość tego pliku opisałem wcześniej, więc nie ma potrzeby zatrzymywania się przy nim w tej chwili.

Test poprawności
A więc podsumowując w chwili obecnej mamy stworzone dwie warstwy aplikacji - biznesową i danych. Stworzony zostały mapowania Hibernate i konfiguracja kontenera IoC. Kompilacja przebiega bez błędów - czas więc przekonać się czy wszystkie mapowania zostały stworzone prawidłowo, czy aplikacja prawidłowo odwołuje się do bazy i pobiera z niej dane.
W tym celu napisałem niewielką aplikację , która za pośrednictwem fabryki Springa odnosi się do interfejsu warstwy biznesowej "IProductManager" , wywołuje na nim metodę, która sięga do warstwy DAO i pobiera obiekty reprezentujące dane przechowywane w DB. A więc do roboty.

Na początku należy przeprowadzić niewielkie czynności przygotowawcze. Najważniejsza z nich wynika z faktu, że nasza aplikacja nie będzie uruchamiana na serwerze aplikacji. Nie ma więc szans wiedzieć czegokolwiek na temat istnienia katalogów "/WEB-INF" i " /WEB-INF/context" ,
a więc miejsc w których przechowywane są pliki konfiguracyjne kluczowych bibliotek: kontenera IoC (Spring) i bibliotek Hibernate. Aby zmienić ten jakże niepożądany stan wszystkie pliki konfiguracyjne muszą znaleźć się w katalogu dopisanego do classpath. W pewnym uproszczeniu (przy założeniu że nasza aplikacja będzie uruchamiana tylko za pośrednictwem IDE) można przyjąć że pliki te powinny znaleźć się w katalogu "src".

Druga rzecz, którą należy wykonać to w skopiowanym (a więc leżącym w katalogu "src"!!!) pliku należy zmienić ścieżkę do pliku z mapowaniami Hibernate z:

<property name="mappingLocations">
<value>/WEB-INF/context/HibernateMapping.hbm.xml</value>
</property>

na

<property name="mappingLocations">
<value>HibernateMapping.hbm.xml</value>
</property>

I to w zasadzie wszystko. Teraz już można zabrać się za pisanie aplikacji.

Niech aplikacja nazywa się "Main" i leży w pakiecie "mw.toystore".

Na początek importy, które zapewnią nam dostęp do obiektów domeny, obiektów fabryki Springa i obiektów warstwy biznesowej:

import java.util.*;
import mw.toystore.domain.*;

import org.springframework.beans.factory.*;
import org.springframework.context.support.*;
import org.springframework.context.*;
import mw.toystore.bus.*;

W pierwszym kroku, w kodzie aplikacji tworzę obiekt kontekstu aplikacji. Przechowuje on informacje o powiązaniach i zależnościach między mapowanymi obiektami. Jako parametr pobiera on nazwy plików, które zawierają mapowania.

ApplicationContext context = new ClassPathXmlApplicationContext(
new String[] {"springapp-servlet-datasources.xml", "springapp-servlet-db.xml", "springapp-servlet-bus.xml"});

Następnie obiekt ten rzutuję na interfejs umożliwiający bezpośredni dostęp do fabryki beanów:

BeanFactory factory = (BeanFactory) context;

Teraz nic nie stoi na przeszkodzie by poprosić o beana z warstwy biznesowej:

IProductManager p=(IProductManager)factory.getBean("productManager");

Następnie wywołuję na nim metodę pobierającą kolekcję kategorii:

List catList=p.getCategoryList();

Następnie iteruję i próbuję wyświetlić nazwę każdej kategorii w kolekcji:

Iterator itcat=catList.iterator();
while(itcat.hasNext()){
Category c=(Category)itcat.next();
System.out.println(c.getName());

}

I to w zasadzie wszystko. Po uruchomieniu aplikacji na ekran wyrzucony został wynik:

"
....
Czasopisma
Broszury
....
"

Brak pojawienia się wyjątku świadczy o tym że mapowania wykonane zostały prawidłowo i o tym, że kontener springa również został skonfigurowany poprawnie.

Zdaję sobie sprawę, że powyższy test był bardzo pobieżny i niezgodny ze sztuką, ale myślę że przy założeniu że piszemy aplikację - tutorial można uznać go za całkowicie wystarczający.

Uff a więc przebiliśmy się przez dużą część materiału. Można śmiało powiedzieć, że nasza aplikacja DZIAŁA ALE NIE WYGLĄDA. Aby wyglądała należy wzbogacić ją o warstwę web i uruchomić na serwerze aplikacji - ale o tym w następnej części.....

Zapraszam do zapoznania się z częścią II artykułu :
ToyStore - skep z zabawkami ( Sitemesh, JSF, Spring, Hibernate, Oracle Express CZĘŚĆ II - WARSTWA WEB

Próba połączenia JSF i Spring - pierwszy kontakt (czyli historia pierwszego uderzenia głową w ścianę)...

Pierwsze problemy z deploy-em

A więc przyszedł czas żeby wprowadzić w życie dawno już powzięty zamiar nauczenia się JSF. Świadomy trudności z jakimi stawia się pierwsze kroki, zaposiłkowany w kilka tutoriali webowych przystąpiłem do realizacji małego projekciku będącego próbką wykorzystania JSF w połączenie ze Springiem - springjsfsample.
Na samym początku zaciągnąłem referencyjną Sun-owską wersję JSF w wersji 1.2 (http://java.sun.com/javaee/javaserverfaces/download.html) i spróbowałem odpalić jeden z dołączonych do nich sampli - jsf-guessNumber. Archiwum wrzuciłem do katalogu deploy i przepełniony radosną niecierpliwością oczekiwałem na reakcje serwera (JBoss 4.0.5). Zachował się przewidywalnie - splunął mi w twarz olbrzymim StackTrace(m):
...
11:35:09,489 ERROR [[/jsf-guessNumber]] StandardWrapper.Throwable
java.lang.IllegalStateException: No Factories configured for this Application. This happens if the faces-initialization does not work at all - make sure that you properly include all configuration settings necessary for a basic faces application and that all the necessary libs are included. Also check the logging output of your web application and your container for any exceptions!
If you did that and find nothing, the mistake might be due to the fact that you use some special web-containers which do not support registering context-listeners via TLD files and a context listener is not setup in your web.xml.
A typical config looks like this;
<listener>

<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
...

Sytuacja nie była za ciekawa. Pierwsze zderzenie z JSF, próba zadeployowania (he ale po polskiemu ! ) aplikacji o złożoności godnej HelloWorld i taki ZONK! Wszedłem w etap intentsywnego googlowania. Pierwszy ślad natrafiłem na stronie JBoss(http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossWithIntegratedMyFaces). Okazuje się że JBoss przychodzi z własną implementacją JSF - MyFaces. Producent przestrzega, że deploy aplikacji, która sama w sobie zawiera biblioteki JSF może zakończyć się porażką. Na szczeście na samym dole znajduje się zdanie, które daje nadzieję na przyszłość:

"Using the JSF Reference Implementation
To use the JSF Reference Implementation instead of the bundled MyFaces implementation, simply delete the jbossweb-tomcat55.sar/jsf-lib directory. Then, package the RI in your WEB-INF/lib directory as usual.
Note: You may also need to delete temp directories such as server/default/tmp and server/default/work.
"

No i wszystko jasne... zrobiłem tak jak mówili.. ale niestety aplikacja z sampla ciągle nie chciała ruszyć...

Postanowiłem zarzucić pomysł deployu standardowych przykładów. Wróciłem do modyfikacji własnej aplikacji -springjsfsample- mając wielkie nadzieje że niedługo powie mi Hello :).

Na początek postanowiłem poczytać trochę w jaki sposób zintegrować JSF-a ze Springiem. Jeden z pierwszych linków, na które trafiłem zaprowadził mnie do projektu jsf-spring - wydawała mi się ona rozwiązaniem którego szukałem. Dostarcza ona bibliotek które mają posłużyć do integracji frameworków. Na stronie projektu znalazłem też ciekawy quickstart, którym postanowiłem się zaposiłkować. W miarę jego realizacji przyszło mi do głowy pewna wątpliwość, a mianowicie czytałem że spring integruje się z jsfem w sposób intuicyjny więc po co wprowadzać dodatkowe biblioteki pośredniczące o których w ogóle nic nie wiem? Pomyślałem że jak uda mi się cokolwiek uruchomić to poszukam innego sposobu połączenia... ale póki co przerobiłem manual, zrobiłem deploy i otrzymałem:

...
11:28:54,870 ERROR [STDERR] 2007-05-12 11:28:54 com.sun.faces.config.ConfigureListener registerELResolverAndListenerWithJsp
SEVERE: Error Instantiating ExpressionFactory
java.lang.ClassNotFoundException: com.sun.el.ExpressionFactoryImpl
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1355)
...

Niby mówi wszystko ale nie do końca bo w standardowej dystrybucji JSF 1.2 pobranej ze strony Sun-a nie ma Jar-a, w którym znalazłaby się ta klasa. Coś tu jest nie tak...

Po solidnej porcji googlania, na jednym z forów trafiłem na opis problemu podobnego do mojego (http://forum.java.sun.com/thread.jspa?threadID=780619&messageID=4463090). Po kolejnych przybliżeniach uczestnicy forum doszli do rozwiązania:

"you can use jsf 1.1 - it works with jsp 2.0 (tomcat 5)
yep jsf 1.2 needs jsp 2.1 to work
jsf 1.2 should work on tomcat 5 too using faclets"

Wiedziony nadzieją zrobiłem tak napisał twórca postu, wróciłem do JSF 1.1, podmieniłem wszystkie Jary w WEB-INF/lib i EUREKA!!!! udało się - dostałem wyjątek którego nazwy już w tej chwili nie pamiętam wyrzucony przez którąś z klas z biblioteki pośredniczącej spring-jsf - a więc poszedłem krok dalej. Zagadka problemów z JSF-em na serwerze JBoss wydała się być rozwiązana.

Realizacja aplikacji:

Ale niestety moja aplikacja springjsfsample ciągle nie działała, więc postanowiłem napisać ją po swojemu,ale po kolei.
Po pierwsze należało zrobić gruntowne porządki w WEB-INF/lib i wyczyścić ślady wszystkich poprzednich eksperymentów. Zostawiłem to co wydawało mi się konieczne, a więc:

• Biblioteki pochodzące z dystrybucji Springa (spring.jar,cglib-nodep-2.1_3.jar)
• Biblioteki pochodzące z dystrybucji JSF 1.1 (commons-beanutils.jar,commons-collections.jar, commons-digester.jar,commons-logging.jar, html_basic.tld, jsf-api.jar, jsf-impl.jar, jsf-spring.jar, jsf_core.tld)
• Biblioteki JSTL (jstl-1.2.jar) - są one wymagane w przypadku używania Sun-owskiej wersji JSF-a

Aplikacja ma być najprostsza jaka tylko może być więc będzie składała się z czterech podstawowych elementów:

1. IHello.java - interfejs który będzie pełnił rolę interfejsu biznesowego
2. HelloBean.java - bean będący implementacją intefejsu biznesoweg IHello
3. UiBean.java - JSF-owy Managed Bean
4. index.jsp - strony jsp

Opis koncepcji:
Mój pomysł był taki, by wykorzystać Springa jako kontener IoC, do zarządzania wszystkimi zależnościami, a JSF miałby pełnić rolę frameworku MVC. Punktem styku pomiędzy obiektami biznesowymi zarządzanymi przez Springa a frameworkiem JSF miałby być obiekt UiBean. To do niego powinien zostać wstrzyknięty interfejs IHello za którego pośrednictwem ten JSF Managed Bean miałby dostęp do warstwy biznesowej.

Pliki aplikacji:

IHello.java

package mw;
import java.util.Date;

public interface IHello {
Date getNow();
String sayHello();
}

HelloBean.java

package mw;
import java.util.Date;
public class HelloBean implements IHello {
public Date getNow() {
return new Date();
}

public String sayHello() {
// TODO Auto-generated method stub
return "I'm your Spring Managed Bean - I'm saying hello to you!";
}
}

UiBean.java

package mw;
import org.springframework.beans.factory.InitializingBean;
public class UiBean implements InitializingBean {
private IHello helloService = null;

public void afterPropertiesSet() throws Exception {}

public String getHello() {
return helloService.sayHello();
}

public IHello getHelloService() {
return helloService;
}

public void setHelloService(IHello helloService) {
this.helloService = helloService;
}
}


Pliki konfiguracyjne:

Na początek WEB-INF/web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>springjsfsample</display-name>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*</url-pattern>
</servlet-mapping>

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

WEB-INF/applicationContext.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">

<beans>
<bean id="uiBean" class="mw.UiBean">
<property name="helloService"><ref bean="helloBean"/></property>
</bean>
<bean id="helloBean" class="mw.HelloBean"/>
</beans>

WEB-INF/faces-config.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE faces-config PUBLIC
"-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"
"http://java.sun.com/dtd/web-facesconfig_1_1.dtd">
<faces-config>
<application>
<variable-resolver>org.springframework.web.jsf.DelegatingVariableResolver</variable-resolver>
</application>

<managed-bean>
<managed-bean-name>uiBean</managed-bean-name>
<managed-bean-class>mw.UiBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>helloService</property-name>
<value>#{helloBean}</value>
</managed-property>
</managed-bean>
</faces-config>

Opis integracji Spring i JSF:

(zastosowany przeze mnie sposób integracji podpatrzyłem w bardzo ciekawym artykule "Spring into JavaServer Faces" autorstwa Michaela Klaene)

Istotą integracji jest niewielki wpis w pliku faces-config.xml :

<application>
<variable-resolver>org.springframework.web.jsf.DelegatingVariableResolver</variable-resolver>
</application>

Powoduje to rozszerzenie możliwości standardowego obiektu VariableResolver, którego zadaniem jest bindowanie obiektów znajdujących się w odpowiednim application scope(session, request).
Element DelegatingVariableResolver jest wywiedziony bezpośrednio z obiektu javax.faces.el.VariableResolver i powoduje, że do zakresu poszukiwań obiektów do bindowania włączony zostanie Spring root WebApplicationContext. Należy zwrócić uwagę na fakt, że nazwa, podana jako klucz wyszukiwania musi być zgodna z identyfikatorem beana zdefiniowanym na poziomie kontekstu springowego, a więc: aby nastąpiło prawidłowe zaincjalizowanie opisane następująco:

<managed-property>
<property-name>helloService</property-name>
<value>#{helloBean}</value>
</managed-property>

W kontekście springa musi znaleźć się definicja beana helloBean, która może wyglądać np. tak (oczywiście pomijam fakt, że nasz managed bean musi mieć właściwość o nazwie helloService i metody dostępowe do niej bo to wydaje się oczywiste):

</bean>
<bean id="helloBean" class="mw.HelloBean"/>
</beans>



Plik WEB-INF/index.jsp

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<f:view>
<html>
<head>
<title>Spring quickstart</title>
</head>
<body>
<h:outputText value="#{uiBean.hello}"/>
</body>
</html>
</f:view>

W pliku tym następuje sięgnięcie do property hello w Managed Bean - UiBean, a w konsekwencji za jego pośrednictwem sięgnięcie do interfejsu biznesowego IHello zarządzanego przez Spring.

Uruchomienie aplikacji

Po kompilacji i pomyślnym deploy-u czas na osteczną organoleptyczną ocenę poprawności:

Po wpisaniu adresu: http://localhost:3333/springjsfsample/index.jsf

otrzymałem efekt:


A więc powtarzając za Mistrzem Boratem :

Great Success :)))))

Materiały:

Źródła aplikacji (war)