Frameworki ORM dla Javy - popularność, JPA 2.0 i inne tematy

Witam wszystkich! Trochę mnie nie było na tym forum, ale zgodnie z porzekadłem "Jak trwoga to do Boga" wracam z prośbą o pomoc :).

Jestem w trakcie pisania pracy magisterskiej na temat zagadnienia mapowania obiektowo-relacyjnego (ORM). Jednym z zadań, które mam wykonać w ramach pracy jest wykonanie porównania frameworków ORM (z zawężeniem do języków opartych na JVM). Ciągle nie mogę się zdecydować na ostateczny wybór frameworków, które będę porównywał.

Chyba dwa najważniejsze kryteria wyboru, jakie sobie przyjąłem to:

1. popularność - jest mnóstwo mniej znanych, często nawet całkiem interesujących rozwiązań, ale niewielki będzie pożytek z ich porównywania, jeśli w komercyjnych rozwiązaniach są one stosowane w śladowych ilościach
2. różnorodność - chciałbym, żeby wybrane rozwiązania w znaczący sposób się od siebie różniły, żeby było co porównywać. Chciałbym się przede wszystkim skoncentrować na porównaniu zakresu funkcjonalności, stopnia złożoności itd, a na ew. testy wydajnościowe poświęcić mniej uwagi, bo jestem do nich sceptycznie nastawiony.

Moimi obecnymi kandydatami są: JPA 2.0/Hibernate Entity Manager, MyBatis (dawniej iBatis) oraz GORM (rozwiązanie ORM wbudowane w framework Grails dla Groovy'ego)

Problem w tym, że pomimo faktu, że sporo już pogooglowałem, to bardzo trudno mi było wyłonić te najpopularniejsze, najlepiej przyjęte rozwiązania. Co do JPA i MyBatis to nie mam wątpliwości, że zdobyły sporą popularność. Czy o GORM'ie można powidzieć podobnie? Z tego co wiem, to Grailsy przyjęły się całkiem nieźle (ale czy wszyscy korzystający z Grailsów korzystają z wbudowanego ORMa czy są ludzie, którzy preferują korzystać z zewnętrznych ORMów?). Czy pominąłem jeszcze coś ważnego, czym warto by się zainteresować i uwzględnić w porównaniu?

Moim początkowym planem było porównanie: Hibernate, EclipseLink, JDO, ponieważ wydawały się najpopularniejsze, ale obecnie wszystkie "podciągnięte" są pod JPA i dlatego oferują bardzo zbliżony zakres funkcjonalności. O ile jeszcze za czasów specyfikacji JPA 1.0 można było robić porównania Hibernate/EclipseLink/JDO w wersji native vs w roli providera JPA, to specyfikacja JPA 2.0 wydaje się na tyle dojrzała i rozbudowana, że zapewnia wszystkie potrzebne usługi (np. język zapytań cryteria, który wcześniej był przewagą korzystania z Hiberante'a w wersji Native zamiast w roli providera JPA). Więc wychodzi na to, że w każdym przypadku lepiej korzystać z framerworku w roli providera JPA 2.0, bo jest dużo zalet, a w zasadzie nie ma wad.

A może się mylę, może wciąż są jakieś istotne feature'y w native Hibernate (hibernate core) czy native EclipseLink, których brakuje w specyfikacji JPA 2.0? Doświadczył ktoś tego?

A więc podsumowując moje pytania: czy oprócz JPA 2.0, MyBatis i GORMa jest jeszcze coś naprawdę godnego uwagi i raczej popularnego? Czy są jeszcze jakieś istotne różnice pomiędzy frameworkami implementującymi JPA 2.0 w wersji native a w wersji providera JPA 2.0? Czy jest jakikolwiek sens zestawiać ze sobą np. Hibernate'a i EclipseLink pod jakimkolwiek względem innym niż wydajność (czy różnią się pomiędzy sobą jeszcze czymś istotnym)?

Każda odpowiedź czy to oparta na osobistym doświadczeniu czy na przeczytaniu kiedyś czegoś byłaby mi bardzo pomocna. Z góry dzięki.

DooM77 napisał(a)

Czy są jeszcze jakieś istotne różnice pomiędzy frameworkami implementującymi JPA 2.0 w wersji native a w wersji providera JPA 2.0?

Co to znaczy 'w wersji native'? Z tego co ja wiem, kazda implementacja JPA / JPA2 pozwala aby uzywac ja za pomoca natywnego API, jak i jako providera JPA. JPA w wersji native to oksymoron.

::. napisał(a)

DooM77 napisał(a)

Czy są jeszcze jakieś istotne różnice pomiędzy frameworkami implementującymi JPA 2.0 w wersji native a w wersji providera JPA 2.0?

Co to znaczy 'w wersji native'? Z tego co ja wiem, kazda implementacja JPA / JPA2 pozwala aby uzywac ja za pomoca natywnego API, jak i jako providera JPA. JPA w wersji native to oksymoron.

Sorry, chyba nieprecyzyjnie się wyraziłem, nie chodziło mi o to, że są osobne wersje danego frameworku, jedna native, druga pod JPA (chociaż w przypadku Hibernate'a tak mniej więcej jest, trzeba dołączyć moduł Entity Manager, żeby móc używać Hibernate jako providera JPA).

Chciałem zapytać właśnie o to czy są jeszcze jakieś rzeczywiste powody, aby korzystać ze wspomnianego przez Ciebie natywnego API zamiast z API JPA. Bo gdyby takie powody były, to mógłbym przeprowadzić rozważanie: w jakim stopniu (i w jakich sytuacjach) dodatkowe możliwości, jakie daje korzystanie z natywnego API rekompensują brak zgodności ze standardami, którą mielibyśmy, gdybyśmy korzystali z danego frameworku spod API JPA. Czyli generalnie mówiać rozważania, co się bardziej opłaca. Na 99% wyszłoby, że to drugie rozwiązanie jest lepsze, ale być może przy okazji poczyniłbym kilka ciekawych uwag.

Tylko jakoś teraz, po powstaniu JPA 2, te "dodatkowe możliwości" natywnych API jakoś trudno mi znaleźć. Te feature'y, które przytaczało się wcześniej jako argument, aby nie korzystać z JPA, tylko natywnego API takiego np. Hiberante'a, jak np. Criteria API czy encje zagnieżdżone znalazła swój odpowiednik w JPA 2. Czy są jeszcze jakieś istotne rzeczy, których brakuje tej specyfikacji? Póki co, zetknąłem się z narzekaniami na brak wsparcia dla hintów do zapytań, umożliwiających ich optymalizację oraz brak odpowiednika Hibernate'owego Manual Flusha (dającego użytkownikowi całkowitą swobodę wyboru momentu, w którym wykonane przez niego zmiany w encjach są wysyłane do bazy danych, a więc nie ograniczają nas granice transakcji, co się przydaje np. do wielokrokowych wizardów, w których chcemy zapisać zmiany dopiero na końcu). Ale te 2 braki to jeszcze za mało, żeby był sens takie porównanie robić :(.

To nie do konca jest tak, Hibrnate tez nie ma 2 roznych wersji, modul entity manager to raptem zastosowanie wzorca Adapter aby Session przystosowac do EntityManager i takie tam. Jest to ciagle jeden i ten sam Hibernate.

Chyba cos wspomniales o hintach - otoz od samego poczatku w JPA jest metoda Query.setHint - dlaczego to nie wystarzca?

Pare rzeczy przchodzi mi do glowy. Np. Hibernate wspiera tzw. User Types - implementujesz klase ktora umie zapisac / odczytac z bazy jakis nowy typ. Jest duzo takich pluginow w necie, chociazby dla biblioteki JodaTime. Przydaje sie, a w JPA2 nie ma i raczej nie bedzie sadzac po tym co sie kiedys dowiedzialem od Emmanuela Bernarda (spec lead dla JPA2) na jakiejstam konferencji. Hibernate ma wsparcie dla multi-tenancy. Jak uzywasz HB, to mozesz dorzucic Hibernate Envers (od 3.6 w core) ktory sluzy do wersjonowanie encji. Masz rowniez Hibernate Search ktory integruje sie z Apache Lucene (wyszukiwanie pelnotekstowe). Te moduly dzialaja tylko i wylacznie z Hibernate. To tak pierwsze lepsze z glowy z rana.

Z kolei my uzywamy EclipseLink 2.x. Tam masz tez pare opcji ktorych nie ma w JPA - duzo mozliwosci do cachowania, tzw. fetch groups, gdzie pola encji grupujesz i dajesz grupom nazwy, i mozesz sprecyzowac kiedy jaka grupa jest zwracana. Sa roznice z hibernate jak procesowane sa encje - np hibernate uzywa Proxy, czego osobiscie nienawidze, a EL uzywa ASM do zabawy z bytecodem, co ostatecznie pozwala na debugowanie i sledzenie kodu w encjach - z tym w HB zawsze mialem jakis problem.

EL od HB rozni sie tym, ze jak w Hb zamknie sie sesje to dostaje sie czasami LazyLoadingException czy jak on sie tam nazywa. Z kolei EL w takich sytuacjach otwiera read-only polaczenie do bazy i sie nie wywala. Pytanie czy ad-hoc transakcje sa dobre i przewidywalne - ja tam wole chyba jednak wyjatek, bo wiem ze musze cos z tym zrobic.

Kazdy dostawca JPA ma swoje wlasne dodatki ktore w ten czy inny sposob wplywaja na perormance / scalowalnosc. Inaczej implementuja cachowanie, EL ma 'in-memory-queries', ktore pozwalaja wywolac JPQL tylko dla obiektow obecnie zaladowanych. Wiecej opcji mapowania, wiecej mozliwosci wykonywania batchow, itp itd - jest calkiem dosc duzo rzeczy ktorymi sie dostawcy roznia, i wszystkie je bardzo czesto mozna wlaczyc / uzyc tylko i wylacznie uzywaja native api.

Zaznaczam ze nie jestem zadnym guru, wiec niektore rzeczy moga byc dostepne i tu i tam, a nawet w JPA2, ale twierdzenie ze JPA2 standaryzuje wszystko jest z pewnoscia nieprawdziwe. Poszukaj, jest duzo informacji.

Piszesz ze szukasz ciekawych uwag. Otoz ja mam jedna - standardy sa do d**y.

To kontrowersyjne pewnie stwierdzenie moge poprzec wlasnym doswiadczeniem. My uzywamy EL ale tylko i wylacznie jako dostawce JPA2, przez co cierpimy wielokrotnie implementujac cos co mozna wlaczyc jedna anotacja - taka polityka, ze ma sie kompilowac z jarem z api JPA i niczym wiecej. Przy czym szefo bardzo sie opiera na second-level cache (co moim zdaniem jest bzdura - bazowac architekture na istnieniu cache jest lipa), ktorego w innym providerze wcale nie musi byc. Roznice w zachowaniu sa dosc znaczne, spec JPA2 tez bardzo czesto zostawia duzo dowolnosci, np kiedy jes flush update wersji (albo gdy wywolasz persist, albo gdy jest flush, albo gdy commit transakcji - praktycznie nie mozna sie dowiedziec, nie maja na to wplywu manualne wywolania flush ani ustawienia, jesli np dzieje sie to podczas commit). Wiele takich roznich sprawilo ze mimo ze kompilujemy sie z jarem jpa, i tak jestesmy przywiazani do EL - hibernate po prostu nie dziala, nasza JPA unit sie nie deployuje, powody sa zalezne od wersji hibernate: a tu bug z embeddedables, a tu bug z jakimis kluczami, itp itd. EL ma tez pelno bugow, jak wszystko, i zdarza sie ze nowsza wersja nie deployuje naszej jednostki bo zaostrzyli jakies kryteria, a specyfikacja jest dwuznaczna (aktualnie mamy taki problem z kolekcjami embeddables i nadpisywaniem pewnych kolumn - specyfikacja milczy na ten temat, EL 2.1.2 dzialal, EL 2.2.0 juz nie, a Hibernate nigdy nie wstawal).

To samo dotyczy EJB 3.x oraz JMS - niby jestesmy zgodni ze specyfikacja, ale jakos nam sie aplikacja na jboss nie deployuje. Nasz app uzywa web profile, ale np caucho resin tez nie smiga - tam sa problemy z kolei z CDI, oni nie uzywaja JBoss Weld tylko wlasnego CanDI, i mozna sie usrac.

Mozliwe ze jestesmy do d**y i robimy wszystko zle. Mozliwe, ale dosc nieprawdopodobne, bo kazdy z nas czytal specyfikacje kilkukrotnie, uzywa ich na co dzien, mamy certyfikaty i takie tam, wiec niezbedna jako taka wiedza jest. Aplikacje z tutoriali w necie faktycznie dzialaja na GF, Jboss, Resin i Bog wie gdzie jeszcze. Nasza jest nieco bardziej rozbudowana niz 5 klas wszystko w jednym module (a-propos wystapien pana Adama Biena z Niemiec i jego 'smoking-testow'), i po prostu nie dziala.

Przede wszystkim: bardzo Ci dziękuje za komentarze, ogromnie mi pomagasz.

Chyba cos wspomniales o hintach - otoz od samego poczatku w JPA jest metoda Query.setHint - dlaczego to nie wystarzca?

Zgoda, taka metoda jest, ale nie ma standardowych hintów poza jednym określonym przez JPA2: javax.persistence.query.timeout. I to też wg specyfikacji: "Portable applications should not rely on this hint. Depending on the persistence provider and database in use, the hint may or may not be observed." Wszystkie inne hinty dalej musza być provider-specific i po przełączeniu się na innego providera będą ignorowane. A więc brakuje sensownego zestawu standardowych hintów wspieranych przez wszystkich providerów.

Np. Hibernate wspiera tzw. User Types - implementujesz klase ktora umie zapisac / odczytac z bazy jakis nowy typ.

Zgadza się, w JPA 2 nie ma wsparcia dla User Types, ale jest już wsparcie dla typów embedded, co już pozwala w jakiś sposób na zapisywanie własnych typów. Na pewno nie daje to takiej elastycnzości jak Hibernate'owe User Types, ale czy w większości przypadków typy embedded nie będą jednak wystarczające?

Jest duzo takich pluginow w necie, chociazby dla biblioteki JodaTime.

Ale daty JodaTime są Serializable, więc - o ile wszystko dobrze rozumiem - JPA może je po prostu zserializować do bazy danych bez żadnych dodatkowych działań ze strony użytkownika (http://www.objectdb.com/java/jpa/entity/types). Co prawda nie będzie to wyglądać zbyt przejrzyście w bazie danych, ale jeśli z bazy danych będzie korzystać tylko nasza aplikacja, to nie będzie to problemem. Rozumiemn, że korzystając z User Types moglibyśmy sprawić, że data Joda Time zapisywałaby się w bazie w czytelnej postaci np. ISO 8601, a przy odczycie obiektu w aplikacji poprawnie konwertowała z powrotem do daty JODA? (http://blog.xebia.com/2009/11/understanding-and-writing-hibernate-user-types/)

Hibernate ma wsparcie dla multi-tenancy.

Czyli nasza aplikacja po stronie serwera może pracować np. dla kilku firm i każdej z nich oferować inny "kontekst", czyli np. udostępniać inne dane? Czy rzeczywiście Hibernate ma jakieś wsparcie dla tego mechanizmu? Doczytałem się tylko, jak można to osiągnąć w Hibernate (http://relation.to/Bloggers/MultitenancyInHibernate), ale żeby Hibernate udostępniał jakieś specjalne klasy lub ustawienia konfiguracyjne wspomagające ten mechanizm to już nigdzie nie znalazłem.

Jak uzywasz HB, to mozesz dorzucic Hibernate Envers (od 3.6 w core) ktory sluzy do wersjonowanie encji.

Hmm, no ale przecież Optimistic Locking, a więc również związane z nim wersjonowanie encji jest dostępny zarówno w starszych wersjach Hibernate'a jak i w JPA już od 1.0 (adnotacja @Version). Czy Hibernate Envers wprowadza coś rzeczywiście nowego/istotnego?

Masz rowniez Hibernate Search ktory integruje sie z Apache Lucene (wyszukiwanie pelnotekstowe).

Słuszna uwaga, zarówno JPA jak i chyba inne ORMy (?) nie oferują wsparcia dla wyszukiwania pełnotekstowego, to jest wyraźna przewaga Hibernate'a.

Sa roznice z hibernate jak procesowane sa encje - np hibernate uzywa Proxy, czego osobiscie nienawidze, a EL uzywa ASM do zabawy z bytecodem, co ostatecznie pozwala na debugowanie i sledzenie kodu w encjach - z tym w HB zawsze mialem jakis problem.

Słuszna uwaga, będę musiał doczytać szczegóły o tym, jakie te rozwiązania mają wady i zalety.

EL od HB rozni sie tym, ze jak w Hb zamknie sie sesje to dostaje sie czasami LazyLoadingException czy jak on sie tam nazywa. Z kolei EL w takich sytuacjach otwiera read-only polaczenie do bazy i sie nie wywala. Pytanie czy ad-hoc transakcje sa dobre i przewidywalne - ja tam wole chyba jednak wyjatek, bo wiem ze musze cos z tym zrobic.

Ale jeśli to działanie EclipseLinka jest to niepożądane w danym projekcie, to chyba można łatwo uaktywnić jakiegoś loggera, żeby na poziomie ERROR logował takie sytuacje czy też w inny sposób powiadamiać developera, że coś takiego ma miejsce? A w ostateczności dzięki temu feature'owi EL zawsze można pokazać szefowi/klientowi "poprawnie" działającą na danym etapie aplikację (czy też po prostu bezstresowo testować aplikację), pomimo że ciągle mamy problemy z zamykaną zbyt wcześnie sesją ;).

Kazdy dostawca JPA ma swoje wlasne dodatki ktore w ten czy inny sposob wplywaja na perormance / scalowalnosc. Inaczej implementuja cachowanie, EL ma 'in-memory-queries', ktore pozwalaja wywolac JPQL tylko dla obiektow obecnie zaladowanych. Wiecej opcji mapowania, wiecej mozliwosci wykonywania batchow, itp itd - jest calkiem dosc duzo rzeczy ktorymi sie dostawcy roznia, i wszystkie je bardzo czesto mozna wlaczyc / uzyc tylko i wylacznie uzywaja native api.

Ok, to chyba będę musiał poszukać trochę głębiej. Nie twierdzę, że przeczytałem wszystko dokładnie, ale raczej oficjalna dokumentacja nie tłumaczy szczegółów wewnętrznego działania frameworku takich jak sposób generacji encji (proxy,asm) czy implementacja cache'a. No ale poszukam lepiej.

Odnośnie cache'a to jest z nim jeszcze taki problem, że jak korzystamy z providera cache'a np. Terracoty, to JPA2 nie oferuje możliwości podpięcia go, trzeba najpierw go podpiąć do providera (co wiąże się z nieprzenośnym kodem/konfiguracją), a potem korzystać z adnotacji @Cacheable nad encjami, które mogą korzystać z cache'a.

Zaznaczam ze nie jestem zadnym guru

Ale mimo wszystko Twoja wiedza o tych zagadnieniach robi naprawdę duże wrażenie.

Zgadzam się ::. na podstawie doświadczeń z EJB 3.0 niby standard ale co inny serwer aplikacyjny to inne bagi lub w ogóle odmienne zachowania.
Jak nieraz słyszę, że jak będe się trzymał standardów EJB/JPA to moją aplikację załaduje na każdy serwer zgodny z tymi standardami.......BZDURA!!!!!!!!!
Takie stwierdzenie dotyczy tylko aplikacji HelloWorld
Też nie korzystam z JPA tylko z hibernate. Wiem, że ma błędy ale znam te błędy i wiem jak je obejść....

1. Hinty zawsze mozesz wstawiac w XML, tam tez mozesz definiowac zapytania. Prawda, nie jest to optymalne rozwiazanie. Ale ustandaryzowanie hintow to nie jest latwe zadanie, poniewaz to jakie zapytanie zostanie wygenerowane ma wplyw na to czy hint ma sens czy nie. A zapytania generowane sa rowniez nieustandaryzowane, i na pewno nie beda. Standaryzowanie hintow ma moim zdaniem maly sens, zawsze znajdzie sie cos co dany provider moze zrobic lepiej za pomoca czegos nowego. Zbyt obszerne standaryzowanie wszystkiego moim zdaniem ograniczyloby innowacyjnosc i konkurencje miedzy providerami - skoro wszyscy wspieraja wszystko i to tak samo, to po co w ogole kilka opcji? A w ten sposob providerzy konkuruja ze soba, bo ten ma to a ten tamto, i na tej podstwawie userzy dokonuja wyboru.
   My dokonalismy wyboru i padlo na EL poniewaz byl on jedynym wtedy (lipiec 2009) providerem (prawie) implementujacym JPA2 i byl reference implemention. Nie za pomoca takich kryteriow powinno sie dokonywac wyboru.

2. Embedded a user types to zupelnie inna brocha. W embedded masz wlasna klase i wymyslasz ktore jej pola / propertisy maja byc zapisywane. User types mozesz ttylko zasymulowac za pomca XML (nie mozesz przeciez anotowac nie swojej klasy z jara) gdy wiesz ktore / sa udostepnione wlasciwosci klasy ktore sa jej 'core'. Czyli np musisz znac jej implementacje i z tego korzystac(co wiadomo jest sliskie - gdy zrobisz update do nowej wersji, tych pol moze juz nie byc), lub klasa musi miec interfejs JavaBean (gettery / settery dla JPA), lub musisz robic wlasny adapter ktory to zapewnia. Jeszcze inna mozliwosc jest pisanie wlasnych hookow @PrePersist oraz @PostLoad w polaczeniu z polami @transient, ktore itp, gdzie nastepuje tlumaczenie czyli to co robi HB. Fakt, masz racje, da sie, wlasnie cos takiego zrobilismy, ale nie jest to az takie wygodne i to tylko proteza - jak juz wczesniej wsomnialem, kaleka implementacja pewnej funkcjonalnosci ktora w HB masz za darmo i dziala.
   Moze czasami Serializable wystarcza, ale jak sam zauwazyles nie jest to czytelne i przypiete do Javy, a nasza baza jest czytana przez innych klientow niz Java - jak oni maja sobie przeczytac ten strumien bajtow? Mamy pisac deserializacje w tych innych jezykach? Ponownie, brudny workaround. Ale moze dla niektorych projektow sie nada. A co jesli chcesz zapisac cos co nie jest Serializable?
   Jak by nie bylo, jest to kolejna rzecz ktora mozesz wykorzystac w porownaniu. Jak bedziesz sam za duzo obalal, to mozesz nigdy nie napisac tej pracy ;d A tak to mozesz wlasnie opisac Twoje uwagi jak mozna temu zapobiec, mozesz nawet sprobowac sam to zaimplementowac i opisac uwagi i doswiadczenia.

3. Multi-tenancy - to wchodzi od HB 4: http://in.relation.to/Bloggers/HibernateCore400Alpha2Release.

4. Optymistic locking sluzy tylko i wylacznie do tego aby rozpoznac konflikty miedzy wieloma klientami zapisujacymi ta sama encje, wersjonowana jest cala encja. Envers to co innego, o wiele wiecej - wersjonowane sa poszczegolne pola, czyli mozesz pokazac np. log zmian danej encji, zbierac i analizowac dane istoryczne itp. Wejdz na ich stronke i zobacz na pierwszej strinie ramke "Envers: Easy Entity Auditing" oraz "Some of its features.". Maly smaczek, Envers napisal Adam Warski, rodak.

5. Logowanie otwierania ad-hoc polaczenia w EL - a jak wykryjesz to polaczenie, aby to zalogowac? No i musisz co jakis czas przegladac logi zeby sprawdzic czy sie nie dzieje cos takiego. Ogolnie takie ad-hoc jest niebezpieczne, pomija transakcje, jak korzystasz z poola polaczen to sie moza okazac zenie ma wolnego polaczenia i aplikacja wisi z nie wiadomo jakiego powodu.
   Ja wole dostac wyjatek na klate, nawet jak pokazuje szefowi. Nie martwia mnie stack tracy, przeciez to normalne, a przynajmniej masz mozliwosc zobaczenia gdzie i kiedy to wystepuje, mozesz w miare latwo zreprodukowac. Ale to moje osobiste zdanie, moze inni to polubia.
   Co do testowania "poprawnej" aplikacji to ja mam zgola odmienne zdanie - to nie jest wcale poprawnie dzialajaca aplikacja, ale masz falszywe poczucie bezpieczenstwa i moze umknac.

6. Terracota i cache - no wlasnie, a taka integracja na pewno juz w necie zrobiona, i dla HB i dla EL, ale nie dla JPA. Ale o ile taki nie-standardowy kod mozna objac w jednej klasie / pakiecie / jarze, ktore mozna wymienic, to nie widze az takiego problemu. Gorzej jakby to sie walalo przez caly codebase. @Cacheable niekoniecnzie musi byc na klasach, w persistence.xml mozna ustawic konfiguracje dla calej aplikacji, a w mappingach XML mozna wylaczac / wlaczac selektywnie. Ponownie, HB i EL maja tutaj znacznie wiecej mozliwsci niz czyste JPA2.

@Szczery - dokladnie to chcialem powiedziec. Uzywanie i kodowanie do standardow daje tylko to (poki co, moze bedzie lepiej), ze kod sie kompiluje. Deployment i runtime to zupelnie inne bajki.

Dzięki serdeczne za pomoc. Nie wszystkie informacje, których mi dostarczyłeś wykorzystałem w pracy magisterskiej, bo nie każdy z tych tematów poruszałem (inaczej prawdopodobnie nigdy bym jej nie skończył ;) ). W każdym razie bardzo dużo się od Ciebie dowiedziałem i podsunąłeś mi kilka istotnych pomysłów. Szacunek dla Ciebie za dużą wiedzę, jaką posiadasz w temacie. Pozdrawiam!