1 2 Previous Next 28 Replies Latest reply on Nov 6, 2010 10:34 AM by oranheim Go to original post
      • 15. Re: JSFUnit with Arquillian example
        pizzapill

        Thank you John, I'll pull this evening/night (GMT+1) and report back about "maven test" etc.

        • 16. Re: JSFUnit with Arquillian example
          pizzapill

          Awesome John, you did it, works like a charm! Thank you so much!

          • 17. Re: JSFUnit with Arquillian example
            oranheim
            Thanks for sharing this example with us. I'm porting a Seam 2 app to Weld/Seam 3, and are re-working my test suite using Arquillian and JUnit. The CDI is just awesome! And not to mention Arquillian. Wow! I can't wait to see all this get into production quality. Nevertheless, I take my chances relying on Alpha and Beta quality and find ways to get through.
            Due to all maven dependencies, including/excluding the right versions. It has been troublesome to put a working POM together, but I think I have a working version that support JPA, CDI, Weld, JSF2, Seam 3, PrettyFaces, PrimeFaces, M2Ecplise project support and an option to run tests in GlassFish and JBoss6 M4 using profiles. You can find my POM at http://na.pastebin.com/AtXBm9st.
            The past couple of days I've been coping with JSFUnit and found that CDI is not properly visible to JSFUnit. Is there a way where I can have my CDI beans available to the ManagedBean facility in JSFUnit?
            I discovered that you can configure all beans in faces-config, however this force me to remove CDI annotations from beans that should be available to be test cases.
            This works:
            // no CDI annotations here
            public class Identity implements Serializable {
            }
            <managed-bean>
            <description>Backing bean for Identity</description>
            <managed-bean-name>identity</managed-bean-name>
            <managed-bean-class>eris.services.security.Identity</managed-bean-class>
            <managed-bean-scope>session</managed-bean-scope>
            </managed-bean>
            client.setValue("username", "username0");
            client.setValue("password", "password0");
            client.click("login-button");
            log.info( "ViewID: " + server.getCurrentViewID());
            assertEquals( "/home.xhtml", server.getCurrentViewID());
            Assert.assertTrue( server.getManagedBeanValue("#{identity.loggedIn}") );
            This does not work:
            @SessionScoped
            @Named
            public class Identity implements Serializable {
            }
            ...
            Assert.assertTrue( server.getManagedBeanValue("#{identity.loggedIn}") );
            The last assertion will fail and return identity.loggedIn = false.
            What practice would you recommend for now? Are there any ways to make JSFUnit have visibility to Weld?

            Thanks for sharing this example with us. I'm porting an app from Seam 2 to Weld/Seam 3, and are re-working my test suite using Arquillian and JUnit. The CDI is just awesome! And not to mention Arquillian. Wow! I can't wait to see all this get into production quality. Nevertheless, I take my chances relying on Alpha and Beta quality and find ways to get through.

             

            Due to all maven dependencies, including/excluding the right versions. It has been troublesome to put a working POM together, but I think I have one now that supports JPA, CDI, Weld, JSF2, Seam 3, PrettyFaces, PrimeFaces, M2Ecplise project support and an option to run tests in GlassFish and JBoss6 M4 using profiles. You can find it at: http://na.pastebin.com/AtXBm9st.

             

            I have a finding with Weld/JSFUnit where CDI is not wired with JSFUnit, hence Weld scoped instances are not visible to JSFUnit. Is there a way where I can have my CDI beans available to the ManagedBean facility in JSFUnit?

             

            I also discovered that you can configure all beans as ManagedBeans in faces-config, in which make them visible to JSFUnit, however this force me to remove CDI annotations from beans that should be available in my production code. So I have to choose. Either write code for Arquillian/JSFUnit using ManagedBeans, or write code for my complete WAR / CDI based deployment.

             

            This works:

             

            {code}

             

                 // no CDI annotations here

                 public class Identity implements Serializable {

                 }

             

                 <managed-bean>

                      <description>Backing bean for Identity</description>

                      <managed-bean-name>identity</managed-bean-name>

                      <managed-bean-class>eris.services.security.Identity</managed-bean-class>

                      <managed-bean-scope>session</managed-bean-scope>

                 </managed-bean>

             

                 client.setValue("username", "username0");

                 client.setValue("password", "password0");

                 client.click("login-button");

                 log.info( "ViewID: " + server.getCurrentViewID());

                 assertEquals( "/home.xhtml", server.getCurrentViewID());

             

                 Assert.assertTrue( server.getManagedBeanValue("#{identity.loggedIn}") );

            {code}

             

             

            This does not work:

             

             

            {code}

             

            @SessionScoped

                 @Named

                 public class Identity implements Serializable {

                 }

             

                 ...

             

                 Assert.assertTrue( server.getManagedBeanValue("#{identity.loggedIn}") );

            {code}

             


             

             

            The last assertion will fail and return identity.loggedIn = false.

             

            What practice would you recommend for now?

             

            Are there any ways to make JSFUnit have visibility to Weld?

            • 18. Re: JSFUnit with Arquillian example
              ssilvert

              Are there any ways to make JSFUnit have visibility to Weld?

               

              Actually, I'm surprised that it doesn't work.  Under the covers, getManagedBeanValue() is calling the same EL resolution code as a Facelet.  So session scope should work.  I'll try to look into that some time next week.

               

              What I can tell you is that I'm working on JSFUnit 2.0.  The plan is to make Arquillian the preferred test runner instead of Cactus.  Also, I'm making JSFSession, JSFClientSession, and JSFServerSession become CDI-injectable.  So your test will look like this:

               

              @Test
              @InitialPage("/index.faces")
              public void testSomething(JSFClientSession client, JSFServerSession server) {
                    client.setValue("input_foo_text", "Stan");
                    client.click("submit_button");
                    UIComponent greeting = server.findComponent("greeting");
                    Assert.assertTrue(greeting.isRendered());
              }
              

               

              Or if you want all tests to use the same starting page you can declare instance variables like this:

               

              @RunWith(Arquillian.class)
              @InitialPage("/index.faces")
              public class MyTestClass
              {
                 private @Inject JSFSession jsfSession;
                 private @Inject JSFServerSession server;
                 private @Inject JSFClientSession client;
              
                 @Test
                 public void testSomething() {
                    this.client.setValue("input_foo_text", "Stan");
                    this.client.click("submit_button");
                    UIComponent greeting = this.server.findComponent("greeting");
                    Assert.assertTrue(greeting.isRendered());
                 }
              }
              

               

              I'd love some early feedback on this.

               

              Stan

              • 19. Re: JSFUnit with Arquillian example
                ssilvert

                Are there any ways to make JSFUnit have visibility to Weld?

                I went ahead and tried this with a @SessionScoped @Named bean.  It worked like a charm.

                 

                Perhaps you forgot to add beans.xml to your WAR when you built it with ShrinkWrap?  As I understand it, you have to put it in your manifest for Arquillian to recognize it as CDI, but you also have to put it in WEB-INF so that the regualr CDI runtime will know to scan your WEB-INF/classes.  So you might need beans.xml in two places.

                 

                WebArchive war =
                         ShrinkWrap.create(WebArchive.class, "test.war")
                            .setWebXML(new File("src/main/webapp/WEB-INF/web.xml"))           
                            .addWebResource(new File("src/main/webapp/WEB-INF/faces-config.xml"), "faces-config.xml")
                            .addWebResource(EmptyAsset.INSTANCE, "beans.xml")
                            .addManifestResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml"));

                 

                Stan

                • 20. Re: JSFUnit with Arquillian example
                  oranheim

                  Hi Stan,

                   

                  The way you manage @InitialPage('..') is great! Look forward to pick up on it

                   

                  Cheers,

                  Ove

                  • 21. Re: JSFUnit with Arquillian example
                    oranheim

                    Stan,
                    I have successfully reproduced CDI wiring with JSUnit. But after some testing and thinking it became clear to me. You test with GlassFish, while I'm testing with JBoss, due to my JPA dependency. I need to use Hibernate EntityManger in JBoss.
                    If you move notxx.properties back to jndi.properties and update your arquillian.xml to point at JBoss; and replace your JSFUnit example POM with this (http://oranheim.pastebin.com/DDxmYGa7), I believe you will get an error with asserting values on your SessionBean. JSFUnit example then breaks with JBoss M4.
                    If you look at the dependency graph for your GlassFish POM (http://pastebin.com/DxisaUF4) and compare that with the JBoss POM (http://pastebin.com/YjYB6GuD) -- they are quite different. Not sure which one is prone to error.
                    I would really appreciate if you looked into this. For my part I will continue to investigate the dependency graph for JBoss tomorrow.
                    Thanks a lot!
                    Ove

                    Stan,

                     

                    I have successfully reproduced CDI wiring with JSUnit. But after some testing and thinking it became clear to me. You test with GlassFish, while I'm testing with JBoss, due to my JPA dependency. I need to use Hibernate EntityManger in JBoss.

                     

                    If you move notxx.properties back to jndi.properties and update your arquillian.xml to point at JBoss; and replace your JSFUnit example POM with this (http://oranheim.pastebin.com/DDxmYGa7), I believe you will get an error with asserting values on your SessionBean. JSFUnit example then breaks with JBoss M4.

                     

                    If you look at the dependency graph for your GlassFish POM (http://pastebin.com/DxisaUF4) and compare that with the JBoss POM (http://pastebin.com/YjYB6GuD) -- they are quite different. Not sure which one is prone to error.

                     

                    I would really appreciate if you looked into this. For my part I will continue to investigate the dependency graph for JBoss tomorrow.

                     

                    Thanks a lot!

                     

                    Ove

                    • 22. Re: JSFUnit with Arquillian example
                      meetoblivion

                      Ove,

                       

                      You can use hibernate persistence.  Just include the latest hibernate (e.g. 3.6.0.Final) in your pom.xml and then execute your tests as usual.  As of when I posted my codebase and pom.xml, jboss as 6 doesn't seem to want to work right in this configuration - i get a lot of missing/broken dependencies.   

                       

                      Just so its clear - that's assuming you want to run against glassfish.

                      • 23. Re: JSFUnit with Arquillian example
                        oranheim

                        If GlassFish can manage my test, I would be more than happy and I gave it a shot. Without Seam Faces it actually works. That's at least the good part.

                         

                        I'm about getting lost here. I have problems testing in JBoss and GlassFish breaks my test cases. I tried to patchwork my test for GlassFish, however this is my current case:

                         

                        - I did not include dependency on Hibernate EntityManager, since I tuned my Entity Beans a little so they deploy just fine in GlassFish

                         

                        - I need to get Seam Faces Alpha 3 into my test cases, so I'm able to perform some conversational stuff

                         

                        - Seam 3 International module doesn't like GlassFish very well, so excluded those dependencies

                         

                        - I added Joda Time 1.6 since Seam Alpha 3 depends on it

                         

                        Now, I'm not able to run any tests at all. The exception I receive is rather cryptic: "exception #0 :null". I wonder what should be in the #0 !?


                        I've read somewhere on the forum that this "exception message" is caused by some wrapped exception further down the stacktrace, but I have no clue on how to capture that.

                         

                        I wish it was possible to run my tests in JBoss M4.

                         

                        PS! My dependency:tree is listed below the stracktrace.

                         

                        Cheers,

                        Ove

                         

                         

                        {code}

                        SEVERE: Exception while loading the app org.glassfish.deployment.common.DeploymentException: Exception #0 :null      at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:167)      at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:125)      at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:224)      at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:338)      at org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:214)      at org.jboss.arquillian.container.glassfish.embedded_3.GlassFishEmbeddedContainer.deploy(GlassFishEmbeddedContainer.java:164)      at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:62)      at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:50)      at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63)      at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115)      at org.jboss.arquillian.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:96)      at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:162)      at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:186)      at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:297)      at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:182)      at org.junit.runners.ParentRunner.run(ParentRunner.java:236)      at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:127)      at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)      at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)      at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)      at org.apache.maven.surefire.Surefire.run(Surefire.java:177)      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)      at java.lang.reflect.Method.invoke(Method.java:597)      at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)      at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) classLoader = WebappClassLoader (delegate=true; repositories=WEB-INF/classes/) SharedSecrets.getJavaNetAccess()=java.net.URLClassLoader$7@49498526 Caused by: org.jboss.weld.exceptions.DefinitionException: Exception #0 :null      at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:45)      at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.fire(ProcessAnnotatedTypeImpl.java:44)      at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:61)      at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:88)      at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:134)      at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:377)      at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:165)      ... 26 more Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 19.301 sec <<< FAILURE! Results : Tests in error:   clickOnRegisterAndRegisterMeber(eris.services.test.logic.MemberRegistrationUITest) Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 [INFO] ------------------------------------------------------------------------ [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] There are test failures. {code}

                         

                         

                        at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:125)
                        at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:224)
                        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:338)
                        at org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:214)
                        at org.jboss.arquillian.container.glassfish.embedded_3.GlassFishEmbeddedContainer.deploy(GlassFishEmbeddedContainer.java:164)
                        at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:62)
                        at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:50)
                        at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63)
                        at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115)
                        at org.jboss.arquillian.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:96)
                        at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:162)
                        at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:186)
                        at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:297)
                        at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:182)
                        at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
                        at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:127)
                        at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
                        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
                        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
                        at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
                        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                        at java.lang.reflect.Method.invoke(Method.java:597)
                        at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
                        at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
                        classLoader = WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
                        SharedSecrets.getJavaNetAccess()=java.net.URLClassLoader$7@49498526
                        Caused by: org.jboss.weld.exceptions.DefinitionException: Exception #0 :null
                        at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:45)
                        at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.fire(ProcessAnnotatedTypeImpl.java:44)
                        at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:61)
                        at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:88)
                        at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:134)
                        at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:377)
                        at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:165)
                        ... 26 more
                        Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 19.301 sec <<< FAILURE!
                        Results :
                        Tests in error:
                          clickOnRegisterAndRegisterMeber(eris.services.test.logic.MemberRegistrationUITest)
                        Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
                        [INFO] ------------------------------------------------------------------------
                        [ERROR] BUILD FAILURE
                        [INFO] ------------------------------------------------------------------------
                        [INFO] There are test failures.

                         

                         

                        Project dependencies:

                         

                         

                        {code}

                        [INFO] [dependency:tree {execution: default-cli}] [INFO] eris.services:eris:war:1.0-SNAPSHOT [INFO] +- commons-lang:commons-lang:jar:2.4:compile [INFO] +- dom4j:dom4j:jar:1.6.1-brew:compile [INFO] +- org.hibernate:hibernate-validator:jar:4.0.0.GA:provided [INFO] |  +- javax.validation:validation-api:jar:1.0.0.GA:provided [INFO] |  +- org.slf4j:slf4j-api:jar:1.5.9.RC1:provided (version managed from 1.5.6) [INFO] |  +- javax.xml.bind:jaxb-api:jar:2.1:provided [INFO] |  |  +- javax.xml.stream:stax-api:jar:1.0-2:provided [INFO] |  |  \- javax.activation:activation:jar:1.1:provided [INFO] |  \- com.sun.xml.bind:jaxb-impl:jar:2.1.3:provided [INFO] +- org.primefaces:primefaces:jar:2.2.M1:compile [INFO] +- junit:junit:jar:4.8.1:test [INFO] +- org.jboss.arquillian:arquillian-junit:jar:1.0.0.Alpha4:test [INFO] |  \- org.jboss.arquillian:arquillian-impl-base:jar:1.0.0.Alpha4:test [INFO] |     \- org.jboss.arquillian:arquillian-api:jar:1.0.0.Alpha4:test [INFO] +- org.jboss.arquillian.framework:arquillian-framework-jsfunit:jar:1.0.0.Alpha4:test [INFO] |  +- org.jboss.arquillian:arquillian-spi:jar:1.0.0.Alpha4:test [INFO] |  +- org.jboss.shrinkwrap:shrinkwrap-impl-base:jar:1.0.0-alpha-11:test [INFO] |  |  \- org.jboss.shrinkwrap:shrinkwrap-api:jar:1.0.0-alpha-11:test [INFO] |  \- org.jboss.shrinkwrap:shrinkwrap-spi:jar:1.0.0-alpha-11:test [INFO] +- org.jboss.jsfunit:jboss-jsfunit-core:jar:1.3.0.Final:test [INFO] |  +- net.sourceforge.htmlunit:htmlunit:jar:2.8:test [INFO] |  |  +- commons-codec:commons-codec:jar:1.4:test [INFO] |  |  +- xerces:xercesImpl:jar:2.9.1:test [INFO] |  |  |  \- xml-apis:xml-apis:jar:1.3.04:test [INFO] |  |  \- commons-logging:commons-logging:jar:1.1.1:test [INFO] |  +- net.sourceforge.htmlunit:htmlunit-core-js:jar:2.8:test [INFO] |  +- org.apache.httpcomponents:httpclient:jar:4.0.1:test [INFO] |  |  \- org.apache.httpcomponents:httpcore:jar:4.0.1:test [INFO] |  +- org.apache.httpcomponents:httpmime:jar:4.0.1:test [INFO] |  +- org.apache.james:apache-mime4j:jar:0.6:test [INFO] |  +- commons-collections:commons-collections:jar:3.2.1:test [INFO] |  +- commons-io:commons-io:jar:1.4:test [INFO] |  +- net.sourceforge.cssparser:cssparser:jar:0.9.5:test [INFO] |  |  \- org.w3c.css:sac:jar:1.3:test [INFO] |  +- net.sourceforge.nekohtml:nekohtml:jar:1.9.14:test [INFO] |  +- xalan:xalan:jar:2.7.1:test [INFO] |  |  \- xalan:serializer:jar:2.7.1:test [INFO] |  \- cactus:cactus:jar:13-1.7.1:test [INFO] |     +- cactus:cactus-ant:jar:13-1.7.1:test [INFO] |     +- commons-httpclient:commons-httpclient:jar:2.0.2:test [INFO] |     +- aspectj:aspectjrt:jar:1.2.1:test [INFO] |     \- cargo:cargo:jar:0.5:test [INFO] |        \- ant:ant:jar:1.5.4:test [INFO] +- org.jboss.seam.faces:seam-faces-api:jar:3.0.0.Alpha3:compile [INFO] +- org.jboss.seam.faces:seam-faces:jar:3.0.0.Alpha3:compile [INFO] +- joda-time:joda-time:jar:1.6:compile [INFO] +- org.jboss.arquillian.container:arquillian-glassfish-embedded-3:jar:1.0.0.Alpha4:test [INFO] |  +- org.jboss.shrinkwrap:shrinkwrap-extension-glassfish:jar:1.0.0-alpha-11:test [INFO] |  +- org.jboss.arquillian.protocol:arquillian-protocol-servlet-3:jar:1.0.0.Alpha4:test [INFO] |  +- org.jboss.arquillian.testenricher:arquillian-testenricher-cdi:jar:1.0.0.Alpha4:test [INFO] |  +- org.jboss.arquillian.testenricher:arquillian-testenricher-ejb:jar:1.0.0.Alpha4:test [INFO] |  \- org.jboss.arquillian.testenricher:arquillian-testenricher-resource:jar:1.0.0.Alpha4:test [INFO] \- org.glassfish.extras:glassfish-embedded-all:jar:3.0.1:provided

                        {code}

                         

                        • 24. Re: JSFUnit with Arquillian example
                          ssilvert

                          Ove Ranheim wrote:

                           

                           

                          Stan,
                          I have successfully reproduced CDI wiring with JSUnit. But after some testing and thinking it became clear to me. You test with GlassFish, while I'm testing with JBoss, due to my JPA dependency. I need to use Hibernate EntityManger in JBoss.
                          If you move notxx.properties back to jndi.properties and update your arquillian.xml to point at JBoss; and replace your JSFUnit example POM with this (http://oranheim.pastebin.com/DDxmYGa7), I believe you will get an error with asserting values on your SessionBean. JSFUnit example then breaks with JBoss M4.
                          If you look at the dependency graph for your GlassFish POM (http://pastebin.com/DxisaUF4) and compare that with the JBoss POM (http://pastebin.com/YjYB6GuD) -- they are quite different. Not sure which one is prone to error.
                          I would really appreciate if you looked into this. For my part I will continue to investigate the dependency graph for JBoss tomorrow.
                          Thanks a lot!
                          Ove

                          Stan,

                           

                          I have successfully reproduced CDI wiring with JSUnit. But after some testing and thinking it became clear to me. You test with GlassFish, while I'm testing with JBoss, due to my JPA dependency. I need to use Hibernate EntityManger in JBoss.

                          I'm on the JBoss AS development team.  I'm certainly not using Glassfish!  I am using JBoss AS6 built from trunk.

                           

                          Unfortunately, I won't be able to look at this any more until next week.  Thanks for all the help in vetting the CDI integration.  JSFUnit/Arquillian/CDI is going to be a great combo.

                           

                          Regards,

                           

                          Stan

                          • 25. Re: JSFUnit with Arquillian example
                            meetoblivion

                            Ove,

                             

                            There's probably a few things to point out.  When using CDI in a managed environment, only the archives within the web app are processed for CDI injection points.  This applies even when starting glassfish from within the test (as is this case).  In order to correctly process those libraries, they need to be added to the libraries in your deployment.

                             

                            Stan,

                             

                            I know for myself at least, I can't get the AS 6 instances up, but it seems like a wide spread maven issue, someone has a bad repo out there that we're all pulling from.

                            • 26. Re: JSFUnit with Arquillian example
                              ssilvert

                              John Ament wrote:

                               

                              Stan,

                               

                              I know for myself at least, I can't get the AS 6 instances up, but it seems like a wide spread maven issue, someone has a bad repo out there that we're all pulling from.

                              John,

                               

                              Are you using embedded mode?  If so then you need to know that there is a problem with jboss-as-depchain.  You have to exclude Seam Core.

                                 <!-- Exclude Seam core.  See JBAS-8503 -->
                                      <dependency>
                                        <groupId>org.jboss.jbossas</groupId>
                                        <artifactId>jboss-as-depchain</artifactId>
                                        <version>${version.jboss_60}</version>
                                        <type>pom</type>
                                        <exclusions>
                                          <exclusion>
                                            <groupId>org.jboss.seam.integration</groupId>
                                            <artifactId>jboss-seam-int-jbossas</artifactId>
                                          </exclusion>
                                        </exclusions>
                                      </dependency>

                               

                              I've found remote mode to be much more reliable and simpler for now.

                               

                              Stan

                              • 27. Re: JSFUnit with Arquillian example
                                meetoblivion

                                Stan,

                                 

                                Yep, embedded mode.  I remember that I had a few errors now :-)

                                 

                                When I run in embedded mode, with JBOSS_HOME defined correctly, I get an error indicating that it does not like the bootstrap.xml

                                 

                                <?xml version="1.0" encoding="UTF-8"?>

                                <!--

                                   The list of URLs for mc beans to load during bootstrap.

                                   $Id: bootstrap.xml 106395 2010-07-02 02:16:59Z mmoyses $

                                -->

                                <bootstrap xmlns="urn:jboss:bootstrap:1.0">

                                 

                                   <url>bootstrap/classloader.xml</url>

                                   <url>bootstrap/stdio.xml</url>

                                   <url>bootstrap/kernel.xml</url>

                                   <url>bootstrap/aop.xml</url>

                                   <url>bootstrap/jmx.xml</url>

                                   <url>bootstrap/deployers.xml</url>

                                   <url>bootstrap/profile.xml</url>

                                   <url>bootstrap/security.xml</url>

                                </bootstrap>

                                 

                                <?xml version="1.0" encoding="UTF-8"?>
                                <!--
                                   The list of URLs for mc beans to load during bootstrap.
                                   $Id: bootstrap.xml 106395 2010-07-02 02:16:59Z mmoyses $
                                -->
                                <bootstrap xmlns="urn:jboss:bootstrap:1.0">
                                   <url>bootstrap/classloader.xml</url>
                                   <url>bootstrap/stdio.xml</url>
                                   <url>bootstrap/kernel.xml</url>
                                   <url>bootstrap/aop.xml</url>
                                   <url>bootstrap/jmx.xml</url>
                                   <url>bootstrap/deployers.xml</url>
                                   <url>bootstrap/profile.xml</url>
                                   <url>bootstrap/security.xml</url>
                                </bootstrap>

                                Here's the full stacktrace:

                                 

                                http://pastebin.com/jT2HjzgC

                                • 28. Re: JSFUnit with Arquillian example
                                  oranheim

                                  Hi,

                                   

                                  I'm able to run my test case in JBoss M4 after I added these libraries to ShrinkWrap:

                                   

                                  {code}

                                  "joda-time:joda-time:1.6" "org.jboss.weld:weld-extensions:1.0.0.Alpha2" "org.jboss.seam.faces:seam-faces-api:3.0.0.Alpha3" "org.jboss.seam.faces:seam-faces:3.0.0.Alpha3" "org.jboss.seam.international:seam-international-api:3.0.0.Alpha1" "org.jboss.seam.international:seam-international:3.0.0.Alpha1" "org.jboss.seam.xml:seam-xml-config:3.0.0.Alpha2"

                                  {code}
                                  I'm able to run my test case in JBoss M4 after I added these libraries to ShrinkWrap:

                                   

                                   

                                  However, now I got some new issues to deal with. After I request page A, write some values to it and submit the form, I'm redirected to Page B. My backing bean is annotated with javax.enterprise.context.SessionScoped. When I'm redirected to Page B, the backing bean is lost. I've tried to resolve the bean value by:

                                  Alt 1:

                                  {code}

                                  server.getManagedBean( "#{mybean.myvalue}" ); Returns null.

                                  {code}

                                   

                                  Alt 2:

                                   

                                  {code}

                                  @Inject BeanManager beanManger on JUnit class, and further resolved my instance of mybean -> myvalue. Returns null.

                                  {code}

                                   

                                  Alt 3:

                                   

                                  {code}

                                  public static BeanManager getBeanManager() {      return (BeanManager) ((ServletContext) FacesContext                .getCurrentInstance().getExternalContext().getContext())                .getAttribute("javax.enterprise.inject.spi.BeanManager"); } @SuppressWarnings("unchecked") public static <T> T getContextualInstance(final BeanManager manager, final Class<T> type) {      T result = null;      Bean<T> bean = (Bean<T>) manager.resolve(manager.getBeans(type));      if (bean != null) {           CreationalContext<T> context = manager.createCreationalContext(bean);           if (context != null) {                result = (T) manager.getReference(bean, type, context);           }      }      return result; } getContextualInstance(getBeanManager(), MyBean.class).getMyValue(); Returns null.

                                  {code}

                                   

                                   

                                  Some thoughts:

                                   

                                  • Resolving managed bean values works fine when you annotate with javax.faces.bean.SessionScoped and in cases where you are *not adding Seam libraries* to ShrinkWrap
                                  • Seam libs also requires you to add the Weld library and I suspect this causes the BeanManager to provide two scopes. One coming from JBoss / Arquillian, and the other from Weld Extension added by ShrinkWrapped, hence I got some classloader issues.

                                   

                                  The interesting bit, is that after form submit my expected value is being returned.

                                   

                                  {code}

                                  client = JSFSession("/pageA.faces").getJSFClientSession(); client.setValue("myvalue", "somevalue"); client.click("submit"); Object value = client.getElement("myvalue").getFirstChild().getNodeValue();

                                  {code}

                                   

                                   

                                  So internally JSF must be doing something right. JSFUnit are able to resolve backing bean values during update models and invoke application phase. But after the request/response, all instances get disposed..

                                   

                                  Could it be that the added Weld Extensions lib to WAR may be the root cause for this inconsistent behavior?

                                   

                                  Cheers,

                                  Ove

                                  1 2 Previous Next