Pokazywanie postów oznaczonych etykietą jsf. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą jsf. Pokaż wszystkie posty

Biblioteka(AndroMDA+JSF+Spring+JPA) -część VI- model dziedziny

Ponieważ moja aplikacyjka nie będzie posiadała zbyt rozbudowanej funkcjonalności, sam model dziedziny również nie będzie zbyt finezyjny :).

Program ma umożliwić rejestrację Wypożyczeń(posiada daty od i do) i Rezerwacji(data rezerwacji) przez Czytelników zarejestrowanych w Bibliotece. Każdy Czytelnik jest Osobą posiadającą swoje imię i nazwisko, oraz numer biblioteczny. Z Czytelnikiem związana jest również lista jego Rezerwacji oraz Wypożyczeń. Rezerwacje i Wypożyczenia dotyczą Książek. Sama Książka posiada swój tytuł, oraz numer katalogowy.Każda Książka mogła zostać napisana przez wielu Autorów (jest to Osoba z imieniem i nazwiskiem, oraz unikalnym identyfikatorem autora).Każdy Autor z kolei mógł napisać wiele Książek.

Myślę że na początek to wystarczy. Pora wykonać model.

Uruchamiam ArgoUML z załadowanym profilem AndroMDA, zakładam pakiet "dziedzina" i przygotowuje projekt. Wygląda on mniej więcej tak:


Dokładna instrukcja, w oparciu o którą tworzyłem obiekty dziedziny zamieszczona jest na stronach dokumentacji cartridge'a EJB3 .

Według mnie na kilka, absolutnie kluczowych zasad należy zwrócić szczególną uwagę.

Przede wszystkim, do naszego projektu powinien zostać załadowany profil AndroMDA dla ArgoUML (o sposobie jego instalowania i osadzania w projekcie pisałem we
wcześniejszym poście
).

Po drugie, wszystkie encje muszą być oznaczone stereotypem "Entity".

Po trzecie, typy dla atrybutów encji muszą pochodzić z załadowanego profilu.

W przypadku ArgoUML, typ atrybutu pochodzący z profilu wygląda tak:


Skoro mój model dziedziny jest już gotowy pora wygenerować kod. W tym celu eksportuje model do formatu xmi (File-Export XMI...). Wygenerowany plik zapisuję jako "biblioteka.xmi" w ścieżce "mda/src/main/uml/biblioteka.xmi".


Teraz tylko uruchomienie pluginu



i następuje przetwarzanie modelu:

INFO  [AndroMDA]   +  registering component 'translation-library'
INFO  [AndroMDA] - core initialization complete: 13.07[s] -
INFO  [AndroMDA] loading model --> 'file:/dane/projekty/sandbox/biblioteka/mda/src/main/uml/biblioteka.xmi'
INFO  [AndroMDA] referenced model --> 'file:/dane/projekty/sandbox/biblioteka/mda/src/main/uml/andromda-profile-32-noextensions.xmi'
INFO  [AndroMDA] - loading complete: 6.005[s] -
INFO  [AndroMDA] - validating model -

Klasy wynikowe, zgodnie z przygotowaną przeze mnie konfiguracją pluginu AndroMDA trafiają do modułu "model", do pakietu "dziedzina"


Kod dla najbardziej złożonej klasy Czytelnik wygląda następująco:

// license-header java merge-point
//
// Attention: Generated code! Do not modify by hand!
// Generated by: EntityEmbeddable.vsl in andromda-ejb3-cartridge.
//
package dziedzina;

import java.io.Serializable;
import java.util.Set;
import java.util.TreeSet;
import javax.persistence.Column;
import javax.persistence.DiscriminatorValue;
import javax.persistence.Entity;
import javax.persistence.NamedQuery;
import javax.persistence.OneToMany;

/**
 * Autogenerated POJO EJB class for Czytelnik containing the
 * bulk of the entity implementation.
 *
 * This is autogenerated by AndroMDA using the EJB3
 * cartridge.
 *
 * DO NOT MODIFY this class.
 *
 * 
 */
@Entity
@DiscriminatorValue("C")
@NamedQuery(name = "Czytelnik.findAll", query = "select czytelnik from Czytelnik AS czytelnik")
public class Czytelnik
    extends Osoba
    implements Serializable
{
    private static final long serialVersionUID = 7232739200991516470L;

    // ----------- Attribute Definitions ------------

    private String numerBiblioteczny;

    // --------- Relationship Definitions -----------

    private Set<Wypozyczenie> listaWypozyczen = new TreeSet<Wypozyczenie>();
    private Set<Rezerwacja> listaRezerwacji = new TreeSet<Rezerwacja>();
    // ---- Manageable Display Attributes (Transient) -----


    // --------------- Constructors -----------------

    /**
     * Default empty constructor
     */
    public Czytelnik() {}

    /**
     * Implementation for the constructor with all POJO attributes except auto incremented identifiers.
     * This method sets all POJO fields defined in this class to the values provided by
     * the parameters.
     *
     * @param imie Value for the imie property
     * @param nazwisko Value for the nazwisko property
     * @param numerBiblioteczny Value for the numerBiblioteczny property
     */
    public Czytelnik(String imie, String nazwisko, String numerBiblioteczny)
    {
        setImie(imie);
        setNazwisko(nazwisko);
        setNumerBiblioteczny(numerBiblioteczny);
    }

    /**
     * Constructor with all POJO attribute values and CMR relations.
     *
     * @param imie Value for the imie property
     * @param nazwisko Value for the nazwisko property
     * @param numerBiblioteczny Value for the numerBiblioteczny property
     * @param listaWypozyczen Value for the listaWypozyczen relation
     * @param listaRezerwacji Value for the listaRezerwacji relation
     */
    public Czytelnik(String imie, String nazwisko, String numerBiblioteczny, Set<Wypozyczenie> listaWypozyczen, Set<Rezerwacja> listaRezerwacji)
    {
        setImie(imie);
        setNazwisko(nazwisko);
        setNumerBiblioteczny(numerBiblioteczny);

        setListaWypozyczen(listaWypozyczen);
        setListaRezerwacji(listaRezerwacji);
    }

    // -------- Attribute Accessors ----------

    /**
     * Get the numerBiblioteczny property.
     * 
     * @return String The value of numerBiblioteczny
     */
    @Column(name = "NUMER_BIBLIOTECZNY", insertable = true, updatable = true)
    public String getNumerBiblioteczny()
    {
        return numerBiblioteczny;
    }

    /**
     * Set the numerBiblioteczny property.
     * @param value the new value
     */
    public void setNumerBiblioteczny(String value)
    {
        this.numerBiblioteczny = value;
    }

    // ------------- Relations ------------------

    /**
     * Get the listaWypozyczen Collection
     *
     * @return Set<Wypozyczenie>
     */
    @OneToMany(mappedBy = "czytelnik")
    public Set<Wypozyczenie> getListaWypozyczen()
    {
        return this.listaWypozyczen;
    }

    /**
     * Set the listaWypozyczen
     *
     * @param listaWypozyczen
     */
    public void setListaWypozyczen (Set<Wypozyczenie> listaWypozyczen)
    {
        this.listaWypozyczen = listaWypozyczen;
    }

    /**
     * Get the listaRezerwacji Collection
     *
     * @return Set<Rezerwacja>
     */
    @OneToMany(mappedBy = "czytelnik")
    public Set<Rezerwacja> getListaRezerwacji()
    {
        return this.listaRezerwacji;
    }

    /**
     * Set the listaRezerwacji
     *
     * @param listaRezerwacji
     */
    public void setListaRezerwacji (Set<Rezerwacja> listaRezerwacji)
    {
        this.listaRezerwacji = listaRezerwacji;
    }

    // -------- Common Methods -----------

    /**
     * Indicates if the argument is of the same type and all values are equal.
     *
     * @param object The target object to compare with
     * @return boolean True if both objects a 'equal'
     */
    public boolean equals(Object object)
    {
        if (this == object)
        {
            return true;
        }
        if (!(object instanceof Czytelnik))
        {
            return false;
        }
        final Czytelnik that = (Czytelnik)object;
        if (this.getId() == null || that.getId() == null || !this.getId().equals(that.getId()))
        {
            return false;
        }
        return true;
    }

    /**
     * Returns a hash code value for the object
     *
     * @return int The hash code value
     */
    public int hashCode()
    {
        int hashCode = super.hashCode();
        hashCode = 29 * hashCode + (getId() == null ? 0 : getId().hashCode());

        return hashCode;
    }

    /**
     * Returns a String representation of the object
     *
     * @return String Textual representation of the object displaying name/value pairs for all attributes
     */
    public String toString()
    {
        StringBuilder sb = new StringBuilder();
        sb.append("Czytelnik(=");
        sb.append(super.toString());
        sb.append("numerBiblioteczny: ");
        sb.append(getNumerBiblioteczny());
        sb.append(")");
        return sb.toString();
    }

}

Żeby dowiedzieć się czy wygenerowany kod jest naprawdę w porządku, przygotuję kilka testów jednostkowych. Tyle że opiszę je już następnym razem....

Biblioteka(AndroMDA+JSF+Spring+JPA) -część V- mapowanie relacji

No i się doczekałem :) konfiguracja skończona. Wreszcie mam środowisko na którym mogę naprawdę się pobawić. Tak jak już pisałem zacznę od modelu dziedziny. Zanim jednak zamodeluję sobie kawałek aplikacji postanowiłem przyjrzeć się jak wygląda kod encji wygenerowany przez framework.Oto krótki przegląd mojego eksperymentu.

Relacje @One-To-One


Asocjacja dwukierunkowa
Na początek spróbuję sprawdzić relację One-To-One zamodelowaną za pomocą relacji asocjacji dwukierunkowej.


Kod po stronie klasy Przedsiebiorca.java
@OneToOne(mappedBy = "przedsiebiorca")
public Adres getAdresDzialalnosciGospodarczej()
{
return this.adresDzialalnosciGospodarczej;
}

Kod po stronie klasy Adres.java
@OneToOne(mappedBy = "adresDzialalnosciGospodarczej")
public Przedsiebiorca getPrzedsiebiorca()
{
return this.przedsiebiorca;
}

No i niestety... od razu problem, bo kod nie jest poprawny. Po obydwu stronach relacji wygenerowana została adnotacja z atrybutem "mappedBy" - framework nie poradził sobie z określeniem właściciela relacji. A więc tak się nie da. Skoro więc nie tak.. to pozostaje pytanie "jak"?
Wskazówkę niesie dokumentacja:

 "To model the owning side of a One-To-One or Many-To-Many bidirectional relationship, you indicate that end (the owning end) of the relationship as an aggregate or composite end. "

A więc wygląda na to, że dwukierunkowa  relacja pomiędzy encjami musi być modelowana przy pomocy agregacji lub kompozycji...Szkoda, bo przecież nie każdy związek pomiędzy obiektami to od razu agregacja lub kompozycja...

Agregacja dwukierunkowa
No to skoro wiem, co mówi teoria, pora spróbować praktyki, jeśli ma być agregacja, to niech będzie agregacja:

Kod po stronie klasy Przedsiebiorca.java
@OneToOne(optional = false, fetch = FetchType.LAZY)
@JoinColumn(name = "ADRES_DZIALALNOSCI_GOSPODAR_FK")
public Adres getAdresDzialalnosciGospodarczej()
{
return this.adresDzialalnosciGospodarczej;
}

Kod po stronie klasy Adres.java
@OneToOne(mappedBy = "adresDzialalnosciGospodarczej")
public Przedsiebiorca getPrzedsiebiorca()
{
return this.przedsiebiorca;
}

A więc tereaz generata jest w porządku. Właściciel relacji został prawidłowo wyodrębniony. Po jego stronie wygenerowany został klucz obcy - więc wygląda że wszystko jest ok.


Asocjacja jednokierunkowa
Relację skierowaną wypróbuję sobie na podstawie asocjacji.



Kod po stronie klasy Przedsiebiorca.java
@OneToOne(optional = false)
@JoinColumn(name = "ADRES_DZIALALNOSCI_GOSPODAR_FK")
public Adres getAdresDzialalnosciGospodarczej()
{
return this.adresDzialalnosciGospodarczej;
}

Kod po stronie klasy Adres.java
BRAK

A więc w przypadku relacji skierowanych, kod wygenerowany na podstawie asocjacji jest już całkowicie poprawny.

Relacje @One-To-Many



Asocjacja dwukierunkowa



Kod po stronie klasy Przedsiebiorca.java
@OneToMany(mappedBy = "przedsiebiorca")
public Set getAdresy()
{
return this.adresy;
}

Kod po stronie klasy Adres.java
@ManyToOne(optional = false)
@JoinColumn(name = "PRZEDSIEBIORCA_FK")
public Przedsiebiorca getPrzedsiebiorca()
{
return this.przedsiebiorca;
}

Powyższy kod jest poprawny, więc wygląda na to, że relacja @OneToMany może być modelowana przy pomocy relacji asocjacji dwukierunkowej.

Ale zaraz... coś tu jest nie tak... właścicielem relacji w UMLu jest klasa Przedsiebiorca.java, a klucz główny został wygenerowany po stronie Adres.java, dlaczego? A więc krótka wycieczka do specyfikacji "ejb-3_0-fr-spec-persistence" i wszystko jasne...
"The many side of one-to-many / many-to-one bidirectional relationships must be the owning
side, hence the mappedBy element cannot be specified on the ManyToOne annotation." 


Właściciel relacji po stronie JPA jest determinowany krotnością elementów, a nie kierunkiem relacji UML-owej. A więc wszystko jasne...

Agregacja dwukierunkowa




Kod po stronie klasy Przedsiebiorca.java
@OneToMany(mappedBy = "przedsiebiorca")
public Set getAdresy()
{
return this.adresy;
}

Kod po stronie klasy Adres.java
@ManyToOne(optional = false)
@JoinColumn(name = "PRZEDSIEBIORCA_FK")
public Przedsiebiorca getPrzedsiebiorca()
{
return this.przedsiebiorca;
}

Tutaj również wygenerowany kod jest poprawny.

Asocjacja jednokierunkowa



Kod po stronie klasy Przedsiebiorca.java
@OneToMany()
@JoinTable
(
name = "PRZEDSIEBIORCA2ADRESY",
joinColumns = {@JoinColumn(name = "PRZEDSIEBIORCA_ID_FK", referencedColumnName = "ID")},
inverseJoinColumns = {@JoinColumn(name = "ADRESY_ID_FK", referencedColumnName = "ID")}
)
public Set getAdresy()
{
return this.adresy;
}

Kod po stronie klasy Adres.java
Brak

Relacje @Many-To-Many

Znany cytat z dokumentacji AndroMDA mówi, że relacja @ManyToMany powinna być modelowana agregacją dwukierunkową.
 "To model the owning side of a One-To-One or Many-To-Many bidirectional relationship, you indicate that end (the owning end) of the relationship as an aggregate or composite end. "



Agregacja dwukierunkowa




Kod po stronie klasy Firma.java
@ManyToMany()
@JoinTable
(
name = "FIRMY2LOKALIZACJE",
joinColumns = {@JoinColumn(name = "FIRMY_ID_FK", referencedColumnName = "ID")},
inverseJoinColumns = {@JoinColumn(name = "LOKALIZACJE_ID_FK", referencedColumnName = "ID")}
)
public Set getLokalizacje()
{
return this.lokalizacje;
}

Kod po stronie klasy Lokalizacja.java
@ManyToMany(mappedBy = "lokalizacje")
public Set getFirmy()
{
return this.firmy;
}

A więc z tą relacją plugin również nie miał problemów. :)

Podsumowanie

Ten krótki przegląd możliwości pluginu w zakresie generowania encji przekonał mnie, że jest on frameworkiem wartym uwagi. Wygenerowany kod źródłowy jest dobrej jakości, a zachowanie pluginu przewidywalne i co rzadko spotykane - dobrze opisane w dokumentacji.
Następnym razem skupię się już na praktycznym zastosowaniu AndroMDA. Opiszę model dziedziny mojej małej aplikacji i sprawdzę czy wygenerowany kod działa na środowisku docelowym (a więc Spring + Tomcat)....

Tymczasem spaaaaać... :)...

Biblioteka(AndroMDA+JSF+Spring+JPA) -część IV- konfiguracja frameworka

Ilość parametrów obsługiwanych przez AndroMDA jest imponująca. Framework jest elastyczny i daje się łatwo dopasowywać do specyfiki projektu. Konfiguracja odbywa się przez parametryzację dwóch plików xml. Nie zamierzam wypisywać wszystkich możliwych do wprowadzenia opcji (tym bardziej, że są one dostępne w oficjalnej dokumentacji). Chciałbym jednak pokrótce wymienić najważniejsze fragmenty konfiguracji i opisać ustawione przeze mnie parametry.

pom.xml (/mda/pom.xml)

Zawartość pliku pom.xml modułu mda opisywałem już jakiś czas temu, dlatego nie będę się na nim skupiał.  Ponieważ na początku mojej przygody z AndroMDA chciałbym ograniczyć się jedynie do wygenerowania persystentnego modelu dziedziny , potrzebny mibędzie tylko jeden cartridge, który posłuży do wygenerowania kodu encji (JPA).

Z tego powodu z sekcji zależności usunąłem prawie całą zawartość, a jedynym wpisem pozostał:

<dependency>
<groupId>org.andromda.cartridges</groupId>
<artifactId>andromda-ejb3-cartridge</artifactId>
<version>${andromda.version}</version>
<scope>runtime</scope>
</dependency>

Dodatkowo, założyłem sobie, że kody wygenerowane przez AndroMDA trafiały będą do modułu "model", dlatego w sekcji właściwości zdefiniowałem sobie stałą wskazującą na umiejscowienie kodów źródłowych tego modułu:

<model.dir>${project.basedir}/../model/src/main/java/</model.dir>

będę się do niej odwoływał, przy konfiguracji cartridge ejb3.

Konfiguracja sposobu przetwarzania (/mda/src/main/config/andromda.xml)

Sercem konfiguracji frameworku AndroMDA jest plik /mda/src/main/config/andromda.xml . Posiada on dosyć czytelną strukturę, która została dobrze opisana w dokumentacji projektu.

1. Sekcja properties
W sekcji tej definiowane są parametry definiujące sposób przetwarzania modelu. Według mnie na szczególną uwagę zasługują dwie flagi:
  • modelValidation - określa czy model jest awalidowany pod kątem zgodności z profilem 
  • outputEncoding - kodowanie plików wynikowych
<properties>
<property name="modelValidation">true</property>
<property name="outputEncoding">true</property>
</properties>

2. Sekcja repositories
W sekcji tej definiowane są źródła, z których zaczytywany jest model, oraz wskazywane są pliki umożliwiające prawidłowe przetwarzanie jego przetwarzanie. Najważniejsze parametry, które ustawić  można w tej sekcji definiowane są w elemencie "model":
  • uri - pozwala na wskazanie ścieżki do pliku modelu
  • moduleSearchLocations - umożliwia wskazanie miejsca, z którego zaczytywane mają być pliki konieczne do przetwarzania modelu (np. pliki profilu)
W moim przypadku sekcja ta wygląda następująco:

<repository name="netBeansMDR">
<models>
<model>
<uri>file:${project.basedir}/src/main/uml/biblioteka.xmi</uri>
<moduleSearchLocations>
<location patterns="**/*.xmi">${project.basedir}/src/main/uml/</location>
</moduleSearchLocations>
</model>
</models>
</repository>
</repositories>


3. Sekcja mappingsSearchLocations
Sekcja ta pozwala na wskazanie lokalizacji, w której znajdują się pliki zawierające mapowania typów umlowych na typy Java.
<mappingsSearchLocations>
<location patterns="*.xml">${conf.dir}/mappings</location>
</mappingsSearchLocations>

4. Sekcja namespaces
Jest to kluczowa sekcja, w której zdefiniowane są aktywne cartridge - czyli biblioteki dokonujące faktycznych przekształceń kodu. Dla każdego z cartridgy możliwe jest podanie całego zatrzęsienia parametrów, które w znaczący sposób dopasowują generatę do indywidualnej specyfiki projektu. W tym miejscu należy zwrócić uwagę na fakt, że każdy użyty cartridge musi zostać wymieniony w /mda/pom.xml w sekcji zależności.
Dobór cartridgy ma decydujący wpływ na formę otrzymanych plików wyjściowych. Np. użycie cartridge "spring" spowoduje wygenerowanie beanów springowych, natomiast cartridge "ejb3" pozwala na wygenerowanie kodów zgodnych z ejb3.

Szczególne znaczenie ma namespace o nazwie "default". Parametry w nim zdefiniowane będą wpływały na każdy inny cartridge.

Na stronie projektu, w sekcjach poświęconych poszczególnym cartridgom możemy odnaleźć dokładną listę parametrów konfiguracyjnych obsługiwanych przez dany cartridge (np dla c. ejb3 strona ta wygląda następująco).

<namespaces>
<namespace name="default">
<properties>
<property name="enableTemplating">true</property>
<property name="enableAnnotations">true</property>
<property name="typeSafeEnumsEnabled">true</property>
<property name="languageMappingsUri">JavaMappings</property>
<property name="wrapperMappingsUri">JavaWrapper</property>
<property name="sqlMappingsUri">${sql.mappings}</property>
<property name="jdbcMappingsUri">JDBC</property>
<property name="maxSqlNameLength">30</property>
<property name="foreignKeySuffix">_FK</property>
<property name="ejbJndiNamePrefix">${application.id}-${project.version}</property>
<property name="enumerationLiteralNameMask">upperunderscore</property>
<property name="persistenceContainerName">jboss</property>
<property name="pluralizeAssociationEndNames">false</property>
<property name="pluralizeAttributeNames">false</property>
<property name="pluralizeParameterNames">false</property>
</properties>
</namespace>

<namespace name="ejb3">
<properties>
<property name="entity-beans">${model.dir}</property>
</properties>
</namespace>
</namespaces>

W powyższej konfiguracji chciałbym zwrócić uwagę na wpis dotyczący cartridgea ejb3
<property name="entity-beans">${model.dir}</property>
Definiuje on miejsce do którego trafiały będą wytworzone artefakty. Stała ${model.dir} zdefiniowana została w /mda/pom.xml .

Biblioteka(AndroMDA+JSF+Spring+JPA) -część III - baza danych

Przed rozpoczęciem pracy nad tworzeniem mojej małej aplikacji muszę zainstalować sobie bazę, w której będe przechowywał dane, oraz wygodne narzędzie, które pozwoli mi na bieżąco śledzić
zmiany w tabelach.

1. Instalacja HSQLDB
Jako bazki danych użyję HSQLDB w wersji 1.8.0. Uruchamiam ją w trybie serwera standalone.

mw@mw:/dane/java/hsqldb-1.8.0/hsqldb/bin> java -cp ../lib/hsqldb.jar org.hsqldb.Server

Po wyświetleniu komunikatów startowych baza wstaje i oczekuje na połączenia.

[Server@156ee8e]: [Thread[main,5,main]]: checkRunning(false) entered
[Server@156ee8e]: [Thread[main,5,main]]: checkRunning(false) exited
[Server@156ee8e]: Startup sequence initiated from main() method
[Server@156ee8e]: Loaded properties from [C:\sandbox\programy\hsqldb_1_8_0_10\hsqldb\bin\server.properties]
[Server@156ee8e]: Initiating startup sequence...
[Server@156ee8e]: Server socket opened successfully in 9 ms.
[Server@156ee8e]: Database [index=0, id=0, db=file:mydb, alias=xdb] opened sucessfully in 273 ms.
[Server@156ee8e]: Startup sequence completed in 291 ms.
[Server@156ee8e]: 2011-09-20 16:03:56.868 HSQLDB server 1.8.0 is online
[Server@156ee8e]: To close normally, connect and execute SHUTDOWN SQL
[Server@156ee8e]: From command line, use [Ctrl]+[C] to abort abruptly

2. Instalacja klienta SQL
Do podglądania zawartości tabel użyję prostego klienta SQL SquirrelSQL (http://www.squirrelsql.org/)


3. Instalacja driverów JDBC i definicja połączenia z serwerem
Żeby podłączyć się do serwera DB, konieczne jest wgranie driverów JDBC. W przypadku HSQLDB należy odnaleźć plik hsqldb.jar (HSQLDB_HOME/lib) i przegrać go do katalogu SQUIRREL_HOME/lib. Po restarcie klienta, drivery automatycznie stają się dostępne i można zdefiniować połączenie do serwera.



Przy definicji połączenia kluczowe jest podanie właściwej wartości Connection String, w moim przypadku ma on postać:
"jdbc:hsqldb:hsql://localhost/xdb"


Teraz tylko należy połączyć się z serwerem i możemy oglądać sobie zawartość naszych tabel.

Definicja springowego DataSource

Teraz muszę zadbać o to by mój projekt korzystał z przygotowanego przeze mnie połączenia do bazy. Muszę odnaleźć definicję springowego DataSource.
Nie jest to trudne, po chwili przeszukiwania trafiam na WEB-INF/config/data-access-config.xml.
Tam odnalazłem definicję źródła danych i ustawiłem właściwy url.
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="org.hsqldb.jdbcDriver" />
<property name="url" value="jdbc:hsqldb:hsql://localhost/xdb"/>
<property name="username" value="sa" />
<property name="password" value="" />
</bean>
Ta zmiana spowoduje, że po inicjalizacji kontekstu springowego, źródłem danych mojej aplikacji będzie przygotowana wcześniej baza danych.

Biblioteka(AndroMDA+JSF+Spring+JPA) -część II - struktura projektu

Wstęp


Chciałbym, aby szkieletem mojej małej aplikacji był Spring Web Flow,warstwę prezentacji zrealizowana była w oparciu o facelety, a warstwa persystentną - w oparciu o JPA. Teraz tylko pozostaje mi znalezienie bazowego projektu mavenowego, w którym zdefiniowane byłyby wymienione przeze mnie zależności(albo chociaż ich część).

Na liście archetypów mavenowych nie znalazłęm tego, czego potrzebuję.

Zajrzałem zatem do przykładowych projektów dostarczanych wraz z dystrybucją Spring Web Flow. I tam natrafiłem na projekt "booking-facets", który według dokumentacji jest zrealizowany w:



* booking-faces: Spring MVC + Web Flow + JavaServerFaces


a więc wygląda że jest dokładnie tym, czego szukam:).

Struktura projektu


Płaska i jednomodułowa struktura projektu "booking-facets" nie bardzo mi się podoba. Na szczęście, dzięki zastosowaniu Mavena, nie jest to problem.Na potrzeby mojej małej aplikacji wydzieliłem sobie kilka modułów powiązanych wzajemnymi relacjami:


mda
model
uslugi
web

  • mda - moduł AndroMDA, którego zadaniem będzie realizacja przekształcenia (PIM->PSM) i generowanie kodu źródłowego modelu na podstawie dostarczonego xmi.
  • model - moduł do którego trafiały będą pliki źródłowe wygenerowane przez AndroMDA. Każda generata modelu będzie czyściła i nadpisywała poprzednią jego zawartość.
  • usługi - do modułu trafiała będzie wykonywana przez programistę implementacja usług działających w oparciu o wygenerowany model. Tu niestety pojawia się problem, bo zawartość modułu nie może być czyszczona po każdej generacie. Różnice wynikające ze zmian modelu muszą być świadomie i "ręcznie" wprowadzone do modelu.
  • web - aplikacja webowa, realizująca GUI, oraz prawidłowy przepływ sterowania
Strukturę projektu, zaimportowanego do Idea pokazuje poniższy zrzut.




Zależności


Jeśli chodzi o zależności to przykładowy projekt springowy potraktowałem prawie jako gotowca... z jedną małą różnicą. Mianowicie główny pom projektu musiał zostać rozbudowany o bibliteki, repozytoria, oraz właściwości wykorzystywane przez plugin AndroMDA (bo przecież do projektu włączyłem go na skutek własnej inicjatywy :)).

Teraz kilka słów o tym jak zrealizowałem to właśnie to włączenie... Posłużyłem się aplikacją wygenerowaną przy pomocy pluginu org.andromda.maven.plugins:andromdapp-maven-plugin:3.4-SNAPSHOT , którą opisałem w jednym z moich poprzednich postów. Do mojego projektu przeniosłem cały wygenerowany tam moduł "mda", a pomy uzupełniłem na wzór stworzonych tam zależności.

Wybrane fragmenty głównego pom.xml mojego projektu, które dotyczą obsługi frameworka AndroMDA wyglądają następująco:

Sekcja właściwości
<properties>
<andromda.version>3.4-SNAPSHOT</andromda.version>
<sql.mappings>
HypersonicSql
</sql.mappings>
<hibernate.dialect>
</hibernate.dialect>
<application.id>mdaprojekt</application.id>
<application.package>mw</application.package>
<application.name>Projekt eksperymentalny</application.name>
<application.version>1.0-SNAPSHOT</application.version>
<dataSource.name>jdbc/${application.id}</dataSource.name>
<dataSource>java:comp/env/${dataSource.name}</dataSource>
</properties>

Sekcja zależności
<dependencies>

<!--AndroMDA-->
<dependency>
<groupId>org.andromda</groupId>
<artifactId>andromda-core</artifactId>
<version>${andromda.version}</version>
<scope>runtime</scope>
<exclusions>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.andromda.translationlibraries</groupId>
<artifactId>andromda-ocl-translation-core</artifactId>
<version>${andromda.version}</version>
<scope>runtime</scope>
<exclusions>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.andromda.translationlibraries</groupId>
<artifactId>andromda-ocl-validation-library</artifactId>
<version>${andromda.version}</version>
<scope>runtime</scope>
<exclusions>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.andromda.cartridges</groupId>
<artifactId>andromda-jsf-cartridge</artifactId>
<version>${andromda.version}</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.andromda.cartridges</groupId>
<artifactId>andromda-jsf-cartridge-components</artifactId>
<version>${andromda.version}</version>
<scope>runtime</scope>
<exclusions>
<exclusion>
<groupId>org.andromda</groupId>
<artifactId>andromda-core</artifactId>
</exclusion>
<exclusion>
<groupId>org.andromda.metafacades</groupId>
<artifactId>andromda-metafacades-uml</artifactId>
</exclusion>
<exclusion>
<groupId>org.andromda.translationlibraries</groupId>
<artifactId>andromda-ocl-validation-library</artifactId>
</exclusion>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.andromda</groupId>
<artifactId>andromda-utils</artifactId>
<version>${andromda.version}</version>
<scope>runtime</scope>
<exclusions>
<exclusion>
<groupId>org.andromda</groupId>
<artifactId>andromda-core</artifactId>
</exclusion>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>
<exclusion>
<groupId>xalan</groupId>
<artifactId>xalan</artifactId>
</exclusion>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.andromda.translationlibraries</groupId>
<artifactId>andromda-ocl-query-library</artifactId>
<version>${andromda.version}</version>
<scope>runtime</scope>
<exclusions>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- This dependency provides the ability to implement your
business logic in an interpreted manner during development on
your local machine -->
<dependency>
<groupId>org.andromda</groupId>
<artifactId>andromda-script-wrappers</artifactId>
<version>${andromda.version}</version>
<scope>runtime</scope>
</dependency>

</dependencies>

Sekcja definicji repozytoriów
<repositories>
<!--AndroMDA -->
<repository>
<id>sonatype</id>
<name>Sonatype AndroMDA Repository</name>
<url>http://oss.sonatype.org/content/groups/public</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>sonatype</id>
<name>Sonatype AndroMDA Repository</name>
<url>http://oss.sonatype.org/content/groups/public</url>
</pluginRepository>
</pluginRepositories>

Definicja pluginu
<plugins>
<!--AndroMDA-->
<plugin>
<groupId>org.andromda.maven.plugins</groupId>
<artifactId>andromda-maven-plugin</artifactId>
<version>${andromda.version}</version>
</plugin>

</plugins>

Jeszcze tylko zwyczajowe

mvn clean install

i uspokajający wynik
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Biblioteka : Spring MVC + Web Flow + JSF/PrimeFaces SUCCESS [1.958s]
[INFO] Biblioteka - mda module ........................... SUCCESS [37.468s]
[INFO] Biblioteka - model ................................ SUCCESS [3.717s]
[INFO] Biblioteka - uslugi ............................... SUCCESS [4.081s]
[INFO] Biblioteka - web module ........................... SUCCESS [24.342s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------


dają nadzieję że o niczym nie zapomniałem :)

A więc opisałem przygotowanie ArgoUML, oraz strukturę mojego projektu. W następnym kroku kilka słów o konfiguacji AndroMDA i można zacząć zabawę :)...

Biblioteka(AndroMDA+JSF+Spring+JPA) -część I- profil dla ArgoUML

Wstęp


Szybki przegląd dokumentacji udostępnionej na stronach projektu AndroMDA zachęcił mnie do praktycznego poeksperymentowania z tym frameworkiem. Założyłem sobie, że zaprojektuje, a potem dokonam implementacji małej, przykładowej aplikacji, która będzie realizowała podstawowe funkcjonalności prostej biblioteki.
Projekt przygotuję w ArgoUML, a AndroMDA posłuży mi jako narzędzie generowania kodu dla Spring Web Flow, którego będę chciał użyć do faktycznej implementacji.

Profil UML

Podstawowym zadaniem, które musi realizować framework bazujący na koncepcji MDA jest wykonywanie automatycznych przekształceń modelu. To z pozoru proste zadanie jest skutecznie komplikowane przez samą naturę języka UML, który dopuszcza dosyć dużą dowolność w posługiwaniu się jego elementami.

W przypadku tworzenia modelu PIM musimy zadbać, by framework został poinformowany o naszych intencjach dotyczących natury definiowanego obiektu (trochę teorii o Model Instance Mapping). Na poziomie realizacji przekształcenia do PSM podjęta musi zostać właściwa decyzja o charakterze generowanego artefaktu (przykładowo inny kod musi być wygenerowany dla obiektu dziedziny - encji, a inny dla bezstanowej klasy usługowej).

Aby rozwiązać ten problem, konieczne jest posługiwaniem się pewnym usystematyzowanym zbiorem reguł i ograniczeń, który będzie zrozumiały zarówno dla projektanta modelu, jak i frameworku dokonującego przekształceń. Stanowi on rodzaj klucza, w oparciu o który wykonana zostanie transformacja.

W przypadku AndroMDA, reguły te zostały opisane przy pomocy Profilu UML. Jest to plik "xmi", w którym zdefiniowany został zestaw typów,stereotypów i tagów, które wykorzystane mogą zostać do tworzenia modelu. Plik ten jest importowany do narzędzia uml, a następnie na etapie konfigurowania frameworku podawany jako podstawa realizacji przekształcenia. Tu należy zwrócić uwagę na fakt, że takie podejście wymusza dużą dyscyplinę pracy przy tworzeniu modelu. Skorzystanie z jakichkolwiek typów, stereotypów, czy elementów spoza dopuszczanych przez profil spowoduje, że model nie przejdzie etapu walidacji i transformacja zakończy się błędem.

Instalacja profilu AndroMDA dla ArgoUML



Na początek należy odnaleźć profil UML przeznaczony dla ArgoUML, który pozwoli nam na właściwe przygotowanie naszego modelu PIM. Nie jest to trudne, krótkie poszukiwanie w Google i trafiam we właściwe miejsce. Ze strony profilu, pobieram zamieszczony tam plik (andromda-profile-32-noextensions.xmi) i zapisuję go na dysk.
Teraz kilka kroków instalacji w ArgoUML i wreszcie można zabrać się do pracy.

1. Rejestracja profilu domyślnego (Edit->Settings->Profiles)
Na początku możemy zarejestrować nasz profil. W tym celu, w ArgoUML uruchamiamy opcję Edit->Settings->Profiles. Otwiera się okno pokazane na zrzucie:



Należy użyć przycisku "Load profile from file...", a następnie wskazać nasz profil. Po zaczytaniu, w polu "Available Profiles" pojawi się nowy wpis. Potem już tylko należy go wskazać i kliknąć w przycisk ">>". Zostanie przeniesienie go do pola "Default Profiles:". U mnie wyglądało to następująco:

Potem "Ok" i zamykamy okienko. Profil jest zarejestrowany.

3.File->Project Properties->Profiles

Teraz należy zadbać o to, by zarejestrowany profil został skojarzony z naszym projektem. W tym celu zakładamy nowy projekt ( u mnie biblioteka.zargo) i uruchamiamy opcje File->Project Properties->Profiles . W okienku "Active Profiles" ma zostać wpis wskazujący na nasz profil. Ma to wyglądać mniej więcej tak:



P.S. Dopiero teraz zauważyłem że okno posiada własny przycisk "Load profile from file...", więc przypuszczalnie kroki opisane w Rejestracji Profilu są zbędne i punkt 1 mógłby spokojnie wylecieć z opisu, ale niech już zostanie :) - może ktoś kiedyś będzie chciał zarejestrować profil domyślny to będą jak znalazł :).

Opisałem w jaki sposób przygotowałem sobie ArgoUML do pracy z AndroMDA. Następnym razem słów kilka o strukturze i organizacji mojego małego projektu.

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