[ Pobierz całość w formacie PDF ]
lizację konfiguracji Hibernate właśnie w ten sposób, by uniknąć dodawania para-
metrów do obiektu Configuration w kodzie aplikacji.
Listing 2.6. Przykładowy plik konfiguracyjny hibernate.cfg.xml
?xml version='1.0'encoding='utf-8'?>
PUBLIC "-//Hibernate/Hibernate Configuration DTD//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd">
true
java:/comp/env/jdbc/AuctionDB
net.sf.hibernate.dialect.PostgreSQLDialect
net.sf.hibernate.transaction.JBossTransactionManagerLookup
Deklaracja typu dokumentu pomaga analizatorowi XML dokonać walidacji
dokumentu, czyli sprawdzić zgodność jego formatu z wytycznymi
zawartymi w DTD pliku konfiguracyjnego Hibernate.
Opcjonalny atrybut name jest równoważny właściwości hibernate.
ses-sion_factory_name. Służy do dowiązania JNDI dla SessionFactory,
co zostanie omówione w dalszej części rozdziału.
Właściwości hibernate można określać bez przedrostka hibernate.
Poza tym przedrostkiem nazwy i wartości są dokładnie takie same jak we
właściwościach ustawianych programowo.
Dokumenty odwzorowań określa się jako zasoby aplikacji lub nawet jako
na stałe zakodowane nazwy plików. Pliki użyte w przykładzie pochodzą
z aplikacji systemu akcyjnego opisywanego w rozdziale 3.
Do inicjalizacji Hibernate wystarczy teraz użycie następującego kodu:
SessionFactory sessions = new Configuration()
.configure().buildSessionFactory();
70 ROZDZIAA 2.
Wprowadzenie i integracja Hibernate
Chwileczkę skąd Hibernate wie, gdzie znajduje się plik konfiguracyjny?
W momencie wywołania metody configure() Hibernate poszukuje pliku
o nazwie hibernate.cfg.xml w ścieżce wyszukiwania klas. Jeśli chce się dla pliku
konfiguracyjnego zastosować inną nazwę lub też plik znajduje się w niestandar-
dowej lokalizacji, do metody configure() należy przekazać ścieżkę.
SessionFactory sessions = new Configuration()
.configure("/hibernate-config/auction.cfg.xml")
.buildSessionFactory();
Stosowanie plików konfiguracyjnych okazuje się bardziej wygodne od plików
właściwości lub programowego ustawiania opcji. Możliwość usunięcia z kodu
lokalizacji plików odwzorowań klas (nawet jeśli miałby się znalezć w pomocni-
czej klasie inicjalizującej) stanowi ogromną zaletę przedstawionego podejścia.
Nic nie stoi na przeszkodzie, by stosować różne zbiory plików odwzorowań (i inne
opcje konfiguracyjne) w zależności od bazy danych i środowiska (produkcyjnego
lub testowego). Co więcej, można je przełączać programowo.
Jeśli ścieżka wyszukiwania klas zawiera pliki hibernate.properties i hibernate.
cfg.xml, ustawienia występujące w pliku XML nadpiszą ustawienia z pliku wła-
ściwości. Rozwiązanie bywa użyteczne, gdy pewne podstawowe ustawienia trzy-
ma się w pliku właściwości i modyfikuje dla każdego wdrożenia plikiem XML.
Warto zwrócić uwagę na nadanie parametru name dla obiektu SessionFactory
w pliku konfiguracyjnym XML. Hibernate używa tej nazwy do automatycznego
dowiązania obiektu do JNDI po jego utworzeniu.
2.4.2. Obiekt SessionFactory dowiązany do JNDI
W większości aplikacji stosujących Hibernate obiekt SessionFactory powinien
zostać utworzony tylko jeden raz w momencie inicjalizacji aplikacji. Cała apli-
kacja powinna stosować ten pojedynczy egzemplarz wszystkie obiekty Session
należy tworzyć na jego podstawie. Często pojawia się pytanie, gdzie umieścić
obiekt fabryki, by był bez trudu dostępny z każdego miejsca aplikacji.
W środowisku J2EE obiekt SessionFactory warto dowiązać do JNDI, by
łatwo udostępnić go wielu wątkom i komponentom wykorzystującym Hibernate.
Oczywiście JNDI to nie jedyny sposób, w jaki komponenty aplikacji mogą uzy-
skać obiekt SessionFactory. Istnieje wiele możliwych implementacji wzorca reje-
stru, włączając w to użycie obiektu ServletContext lub zmiennej static final
w obiekcie singletonu. Szczególnie eleganckim wydaje się być rozwiązanie sto-
sujące komponent szkieletowy odwrócenia sterowania (IoC Inversion of Con-
trol) o zasięgu całej aplikacji. JNDI jest popularnym rozwiązaniem udostępnianym
jako usługi JMX, co wkrótce pokażemy. Niektóre alternatywy przedstawimy
w podrozdziale 8.1.
Obiekt SessionFactory automatycznie dowiąże się do JNDI, gdy właściwość
hibernate.session_factory_name będzie zawierała nazwę węzła katalogu. Jeśli
środowisko wykonawcze nie zapewnia domyślnego kontekstu JNDI (lub też do-
myślna implementacja JNDI nie obsługuje egzemplarzy interfejsu Reference-
2.4. Zaawansowane ustawienia konfiguracyjne 71
able), należy wskazać kontekst JNDI, używając właściwości hibernate.jndi.
url i hibernate.jndi.class.
Uwaga Interfejs programistyczny JNDI umożliwia zapisywanie i odczyt obiektów
w strukturze hierarchicznej (drzewiastej). JNDI implementuje wzorzec
[ Pobierz całość w formacie PDF ]