Azt szeretném kérdezni, hogy mit javasoltok EJB Service-ek tesztelésére? Jelenleg Glassfish 3.1.2-t használok, mint alkalmazásszervert Hibernate-el, így adta magát az embedded glassfish. Na, ezzel az a problémám, hogy eclipse-link-el mennek a tesztek, de a hibernate-el nem, pedig az alkalmazás ugye működik vele. Kapok ClassNotFoundException-ket, amik persze a glassfish lib-je alatt vannak, nem értem miért nem tölti be... A JEEUnit-ot találtam még, de ki sem próbáltam, mert ear projekthez nem jó a leírás alapján. Van még az Arquillian, de legutóbbi tapasztalataim alapján inkább nem választanám. Bár lehet sokat javult... Akkor még lenne még egy lehetőség, hogy CDI-al kicserélem alternative Bean-ekre a Service dolgaimat és a tranzakciót resource_local-al saját Interceptorral kezelném. de ez sem igazán tetszik, hisz elvileg nekem csak valami teszt container kellene és egy teszt persistence.xml és nem kellene szórakoznom CDI teszt bean-ekkel. Van valami javaslatotok?
6 Comments
Auth Gábor
Annyira speciális lekérdezést használsz, amihez mindenképpen Hibernate kell?
Simon László
Őszintén szólva nem... viszont utánaolvasva pár dolognak a Hibernate mellett döntöttem. Egyrészt szeretném a HibernateSearch-el a FullTextQuery-t megvalósítani, és úgy tudom ez nem megy EclipseLink-el, valamint a teszteket olvasva jobb teljesítménye van a Hibernate-nek(igaz bugosabb is)
Auth Gábor
Ezek szerint mégis használsz Hibernate specifikus dolgokat, vagy legalábbis tervezed...
Valahogy biztos meg lehet oldani, hogy a Hibernate működjön Glassfish-el, az nem oldja meg, ha a teszteléshez összerakott war/ear tartalmazza a hibernate.jar-t is?
Jah, én a Hibernate-et két dolog miatt nem szeretem:
Simon László
Ez a jó kifejezés, tervezem, hogy lesznek Hibernate specifikus dolgok!
nem egészen értem, mire gondolsz, mert ez egy maven multimodul projekt. A Service modulomban/jarban vannak az EJB service-im, amit a maven testben a glassfish-embedded-static-shell-el futtatnék. Ez annyit csinál, hogy elindítja a Glassfish-t és gondolom a classes alatt lévő beaneket berántja és a JUnit tesztemben meg lookup-al kivenném a service-t és lefutnának a teszteseteim. Ebben az esetben gondolom a Glassfish lib-je alatt kellene keresnie a Hibernate jar-t. nem tudom hova tehetném még?
Hát igen, Hibernate-nek megvan ez lazy loading problémája és a jelenlegi probléma meg azért nem jön elő eclipselinkel, mert az bytecode-ból művészkedik, míg a hibernate a javaassist-al és dinamikus proxyval. Legalábbis ezt írják a neten.
Auth Gábor
Ahja, én úgy csináltam, hogy így hoztam létre a Glassfish példányt: ServiceLocatorTest.java, tehát összeraktam dinamikusan egy telepítendő war alkalmazást, amelyet bele deploy-oltam és így hívogattam.
Simon László
Hát igen, de így kellenek Remote Interface-ek és ugye én azt szeretném, hogy maven buildnél ez automatikusan lefusson. Persze, ezt is meg lehetne hekkelni, hogy létrehozza a teszt ear-t majd felmásolja a glassfish alá és elindítsa és behívogasson, de valahogy ez nem tetszik.
lehet az lesz, hogy CDI-ra átírom a JUnit tesztjeimet, így igaz nem container menedzselt lesz, de szinte ugyanaz lesz és ráadásul sokkal gyorsabb lesz, mert nem kell megvárni, hogy elinduljon a glassfish. Azon is elgondolkoztam, hogy érdemes-e JEE-t "erőltetni", mert lehet kevesebb problémám lenne spring-el a tesztelésnél. Mondjuk ott meg a konfigurálgatás az ami időigényes...