Child pages
  • EJB + JUnit
Skip to end of metadata
Go to start of metadata

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?

      
      
Page viewed times
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels

6 Comments

  1. Annyira speciális lekérdezést használsz, amihez mindenképpen Hibernate kell?

     

  2. Ő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)

  3. Ezek szerint mégis használsz Hibernate specifikus dolgokat, vagy legalábbis tervezed... (smile)

    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:

    • Képesek sub-minor váltásnál olyan módosításokra, amelytől a megírt HQL egyszercsak nem működik
    • Hatalmas szívás a lazy loading, mert a Hibernate Session lezárása után már kivételt dob, az EclipseLink visszanyit egy kapcsolatot és megoldja.

     

  4. Ez a jó kifejezés, tervezem, hogy lesznek Hibernate specifikus dolgok! (smile)

    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.

     

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

  5. 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. (smile)

    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. (smile) 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...