1 2 Previous Next 19 Replies Latest reply on Apr 5, 2013 12:01 PM by brevilo

    [warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication

    brevilo Newbie

      Hi everyone,

       

      I'm currently trying to use Warp JSF (1.0.0.Alpha2) to test an application that uses FORM-based authentication. The test code itself is pretty much standard, using WebDriver (htmlunit) via Drone:

       

       

          @Drone
          WebDriver browser;
      
          @ArquillianResource
          URL deploymentUrl;
      
          @Test
          @RunAsClient
          public void testWarpJSF() {
              Warp.initiate(new Activity() {
                  @Override
                  public void perform() {
                      browser.get(deploymentUrl + "index.xhtml");
                      doLoginIfNeeded(browser);
                      // this works just fine!
                      Assert.assertEquals("TITLE", browser.getTitle());
                  }
              })
              .inspect(new Inspection() {
                  private static final long serialVersionUID = 1L;
      
                  @ArquillianResource
                  FacesContext facesContext;
      
                  @AfterPhase(RENDER_RESPONSE)
                  @SuppressWarnings("unused")
                  public void testOnServer() {
                      // timeout before we reach this
                      Assert.assertEquals("/index.xhtml", facesContext.getViewRoot().getViewId());
                  }
              });
          }
      

       

      When all security-constraints are disabled the test works as expected. When the security-constraints are in place other client-side tests also work just fine and even the Activity instance is doing its job during initiate() as verified by the first assert (login occured, target page loaded). However, inspect() hits a ServerResponseTimeoutException:

       

      org.jboss.arquillian.warp.impl.client.execution.SynchronizationPoint$ServerResponseTimeoutException
                at org.jboss.arquillian.warp.impl.client.execution.SynchronizationPoint.awaitResponses(SynchronizationPoint.java:155)
                at org.jboss.arquillian.warp.impl.client.execution.DefaultExecutionSynchronizer.waitForResponse(DefaultExecutionSynchronizer.java:60)
                at org.jboss.arquillian.warp.impl.client.execution.WarpExecutionObserver.awaitResponse(WarpExecutionObserver.java:64)
                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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
                at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
                at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
                at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
                at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
                at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
                at org.jboss.arquillian.warp.impl.client.execution.DefaultWarpExecutor.awaitServerExecution(DefaultWarpExecutor.java:95)
                at org.jboss.arquillian.warp.impl.client.execution.DefaultWarpExecutor.execute(DefaultWarpExecutor.java:65)
                at org.jboss.arquillian.warp.impl.client.execution.WarpExecutionObserver.executeWarp(WarpExecutionObserver.java:45)
                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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
                at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
                at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
                at org.jboss.arquillian.warp.impl.client.execution.WarpExecutionInitializer.provideWarpContext(WarpExecutionInitializer.java:64)
                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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
                at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
                at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
                at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
                at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
                at org.jboss.arquillian.warp.impl.client.execution.DefaultWarpRequestSpecifier.execute(DefaultWarpRequestSpecifier.java:98)
                at org.jboss.arquillian.warp.impl.client.execution.DefaultWarpRequestSpecifier.inspect(DefaultWarpRequestSpecifier.java:76)
                at [mytestclass]
                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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
                at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
                at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
                at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
                at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
                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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
                at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
                at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
                at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
                at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
                at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
                at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
                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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
                at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
                at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
                at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
                at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
                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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
                at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
                at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
                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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
                at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
                at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
                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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
                at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
                at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
                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.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
                at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
                at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
                at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
                at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
                at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
                at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
                at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
                at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
                at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
                at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
                at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
                at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
                at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
                at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
                at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
                at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
                at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
                at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
                at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
                at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
                at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
                at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
                at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
                at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
                at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
                at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
                at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
                at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
      

       

       

      Just a shot in the dark but could this be related to ARQ-1291 somehow? This also sounds pretty much like ARQ-992 (redirect caused by login form/process?) and its related issues but those should have been resolved in Alpha2. I also tried the HTTP request filter group approach demonstrated here, but to no avail (same exception).

       

      Any idea what's wrong?

       

       

      Cheers

        • 1. Re: [warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication
          Lukáš Fryč Master

          Hey brevilo,

           

          I don't think you hit ARQ-1291 since you don't use observe() method.

           

          The Warp.initiative().observe(); API actually warps only first request - whatever the request it is. It might be first cause - you are enriching a wrong request.

           

          My usual pattern to investigate this kind of issues is enabling Arquillian debug mode on both, server and client: just pass -Darquillian.debug=true to both VMs (test and server).

          This will reveal what requests are actually warped and it will bring a little bit more clarity to what has happened.

           

          ----

           

          It appears to me that we should really try improve the message for this exception:

          • what a request was Warp waiting for
          • add a suggestion how to resolve an issue

           

          I have created following issue to cover this: ARQ-1361

          • 2. Re: [warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication
            brevilo Newbie

            Hi Lukáš,

             

            Thanks for getting back to me so quickly, I really appreciate your work and Warp in particular.

             

            I'll definitely try to debug the situation and will keep you posted about my findings. In the meantime though, can you please shed some light on whether my approach should indeed be working when using FROM authentication? I already tried to use request observers (e.g. group().observe(request().uri().contains("index.xhtml"))) but that didn't change anything - and I don't know whether that's necessary at all in my particular situation. I guess my main question is: what's the canonical initiate/[group/observe]/inspect/[execute] workflow to inspect a page protected by FORM authentication?

             

             

            Thanks again!

            • 3. Re: [warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication
              brevilo Newbie

              Update, this is the Arquillian client-side debug output:

               

               

              (E) Before
                        (I) TestContextHandler.createSuiteContext
                        (I) TestContextHandler.createClassContext
                        (E) TestClass
                        (I) TestContextHandler.createTestContext
                        (I) ContainerEventController.createBeforeContext
                        (O) TestInstanceEnricher.enrich
                        (E) BeforeEnrichment
                        (E) RequireProxy
                                  (O) ProxyObserver.requireProxy
                        (E) AfterEnrichment
                        (O) DroneConfigurator.configureDrone
                        (O) ClientBeforeAfterLifecycleEventExecuter.on
              (E) Test
                        (I) TestContextHandler.createSuiteContext
                        (I) TestContextHandler.createClassContext
                        (E) TestClass
                        (I) TestContextHandler.createTestContext
                        (I) ContainerEventController.createTestContext
                        (O) ClientTestExecuter.execute
                        (E) ExecutionEvent
                                  (O) LocalTestExecuter.execute
                                  (E) ExecuteWarp
                                            (I) WarpExecutionInitializer.provideWarpContext
                                            (E) WarpContext
                                            (E) SynchronizationPoint
                                            (O) WarpExecutionObserver.executeWarp
                                            (E) AdvertiseEnrichment
                                                      (O) WarpExecutionObserver.advertiseEnrichment
                                            (E) FinishEnrichment
                                                      (O) WarpExecutionObserver.finishEnrichment
                                            (E) Activity
                                                      (O) WarpExecutionObserver.executeActivity
              (E) FilterRequest
                        (O) EnrichmentObserver.tryEnrichRequest
                      (R) /test/index.xhtml
                        (E) EnrichRequest
                                  (O) EnrichmentObserver.enrichRequest
                              (W) /test/index.xhtml
              (E) FilterResponse
                        (O) EnrichmentObserver.tryDeenrichResponse
                                            (E) AwaitResponse
                                                      (O) WarpExecutionObserver.awaitResponse
                                                      (E) ServerResponseTimeoutException
                                                      (E) ServerResponseTimeoutException
                                            (E) CleanEnrichment
                                                      (O) WarpExecutionObserver.cleanEnrichment
                                  (E) TestResult
              (E) After
                        (I) TestContextHandler.createSuiteContext
                        (I) TestContextHandler.createClassContext
                        (E) TestClass
                        (I) TestContextHandler.createTestContext
                        (I) CreationalContextDestroyer.destory
                        (I) ContainerEventController.createAfterContext
                        (O) ClientBeforeAfterLifecycleEventExecuter.on
                        (O) DroneDestructor.destroyMethodScopedDrone
              
              

               

              This doesn't provide any new insight, at least not to me ;-) The enrichment, warping and filtering all look good to me. The server-side log doesn't reveal anything unusual either (no difference in passed tests and failed test)...

               

              Does this help?

               

               

              Best

              • 4. Re: [warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication
                Lukáš Fryč Master

                I don't know what specifically needs to be done to test form-based authentication.

                Just note it's out of Warp's concerns - it is designed to wait for particular request and inspect it, nothing more.

                 

                But I have two concerns where Warp might get buggy:

                 

                • the NonWritingResponse prevents Servlets to write the response directly (since we need to write an HTTP header on the end of the request)
                • the response has everytime status=200 to allow carrying a arbitrary payload (it is changed to original value on client-side proxy)

                 

                Those are manipulations which can simply affect your use case - that's why we have decided to reiplement Warp with independent communication channel instead of piggy-backing/wrapping (ARQ-1325) which will be done in upcoming release.

                Jakub did some changes in favor of NonWritingResponse compliancy, so you may give a 1.0.0.Beta1-SNAPSHOT shot - it might fix your issue.

                • 5. Re: [warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication
                  brevilo Newbie

                  I don't know what specifically needs to be done to test form-based authentication.

                  Just note it's out of Warp's concerns - it is designed to wait for particular request and inspect it, nothing more.

                  Sure, no problem. I was just hoping that, since FORM authentication (j_security_check) is a standard Java EE 6 feature, you'd be aware of its internals or request workflow.

                  give a 1.0.0.Beta1-SNAPSHOT shot - it might fix your issue.

                  I tried the latest snapshot as of today (e.g. arquillian-warp-impl-1.0.0.Beta1-20130325.153157-106.jar) but then none of my tests worked anymore with authentication enabled, neither client-side nor server-side.

                   

                  The tests all fail like this:

                   

                  java.lang.IllegalStateException: Error launching test at http://0.0.0.0:8888/test/CommandEventBus?className=TestClass&methodName=testStuff&operationMode=GET. Got 302 (Moved Temporarily)
                            at org.jboss.arquillian.warp.impl.client.eventbus.CommandEventBus.execute(CommandEventBus.java:266)
                            at org.jboss.arquillian.warp.impl.client.eventbus.CommandEventBus.access$100(CommandEventBus.java:67)
                            at org.jboss.arquillian.warp.impl.client.eventbus.CommandEventBus$2.run(CommandEventBus.java:147)
                            at java.util.TimerThread.mainLoop(Timer.java:555)
                            at java.util.TimerThread.run(Timer.java:505)
                  
                  or
                  
                  java.lang.IllegalStateException: Error launching test at http://0.0.0.0:8888/test/CommandEventBus?className=TestClass&methodName=testStuff&operationMode=PUT. Got 302 (Moved Temporarily)
                            at org.jboss.arquillian.warp.impl.client.eventbus.CommandEventBus.execute(CommandEventBus.java:266)
                            at org.jboss.arquillian.warp.impl.client.eventbus.CommandEventBus.executeCommandRemotely(CommandEventBus.java:194)
                            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
                            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                            at java.lang.reflect.Method.invoke(Method.java:601)
                            at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
                            at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
                            at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
                            at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
                            at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
                            at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
                            at org.jboss.arquillian.warp.impl.client.eventbus.RemoteSuiteLifecyclePropagation.sendBefore(RemoteSuiteLifecyclePropagation.java:51)
                            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
                            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                            at java.lang.reflect.Method.invoke(Method.java:601)
                  

                   

                  Something I noticed: port 8888 is bound to HTTP which I redirect to HTTPS on 8889. Could this be part of the problem?

                   

                  FYI, as with 1.0.0.Alpha2, as soon as I deactivate the security-constraints/authentication the tests all work just fine with 1.0.0.Beta1-SNAPSHOT. Please also note that the client-side test did work with authentication enabled and 1.0.0.Alpha2, so at least the failing client-side tests could be considered a regression in 1.0.0.Beta1-SNAPSHOT.

                   

                  Seems like this whole authentication business justifies a dedicated test case... ;-)

                   

                   

                  Best

                  • 6. Re: [warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication
                    Lukáš Fryč Master

                    Okay, we got not just one, but rather two issues. :-)

                     

                    CommandEventBus isn't obviously ready for situations when it is being redirected (let's fix it) -> could you please create a new issue?

                    We will depend on this service heavily in the future, so it is critical for Alpha3/Beta1.

                     

                    Authentication is then another hard nut - could you possibly help me to put together a test case which would reproduce it?

                    It needs to be placed here: https://github.com/arquillian/arquillian-extension-warp/tree/master/ftest

                    It also deserves a new issue to be created.

                    • 7. Re: [warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication
                      brevilo Newbie

                      Sounds like a plan. I'll look into it over the next few days.

                       

                      Cheers

                      • 8. Re: [warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication
                        brevilo Newbie

                        Update: I created the two issues (see related issues of this thread). How do we want to go about the test case? I can certainly come up with the test itself but it'll require a certain configuration of the JBoss instance (standalone.xml) used to run the test. We need to configure the web subsystem to do redirects (note to self: maybe we can omit the SSL nature here?) and the security subsystem needs to get a configured security-domain.

                         

                        Cheers

                        • 9. Re: [warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication
                          Lukáš Fryč Master

                          It would help if we omit SSL at all - not sure the security subsystem will allow this.

                           

                          If that will be necessary, we can emulate some part of this behavior with a custom filter which would emulate it.

                           

                          The custom JBoss AS is option as well, but I would discourage to introduce complexity if it's not necessary.

                          • 10. Re: [warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication
                            brevilo Newbie

                            I agree, however, I don't know any way around the standalone.xml changes since that's how the security stuff is implemented in JBoss. I think we should answer the following questions before we implement the test cases:

                            • Do we require that tests run more or less independent of the current test container config (e.g. because of continous integration constraints)? If so, the required tests don't seem feasible.
                            • If we can't depend on standalone.xml tuning for web/port redirects or security-domains/authentication, are there suitable emulations or workarounds available? If not, the required tests don't seem feasible.
                            • If the tests are infeasible because of the above, do we want to implement the tests anyway such that others may use them as example or for manual test runs? If so, I'll add them to the repo and issue a merge request.

                             

                            FYI: if we implement the changes and if they are supposed to run in a given CI system, the test container can be prepared to handle authentication without affecting its normal operation. The redirect configuration however would impact the existing config since normal HTTP access would always be redirected.

                             

                             

                            Best

                            • 11. Re: [warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication
                              Lukáš Fryč Master

                              Oliver Bock wrote:

                               

                              I agree, however, I don't know any way around the standalone.xml changes since that's how the security stuff is implemented in JBoss. I think we should answer the following questions before we implement the test cases:

                              • Do we require that tests run more or less independent of the current test container config (e.g. because of continous integration constraints)? If so, the required tests don't seem feasible.
                              • If we can't depend on standalone.xml tuning for web/port redirects or security-domains/authentication, are there suitable emulations or workarounds available? If not, the required tests don't seem feasible.
                              • If the tests are infeasible because of the above, do we want to implement the tests anyway such that others may use them as example or for manual test runs? If so, I'll add them to the repo and issue a merge request.

                               

                              FYI: if we implement the changes and if they are supposed to run in a given CI system, the test container can be prepared to handle authentication without affecting its normal operation. The redirect configuration however would impact the existing config since normal HTTP access would always be redirected.

                               

                               

                              Best

                               

                              Note: the problem with the ftests are that they should be portable to various compliant application servers.

                               

                              So even though we would be able to manage containers manually from ftest and configure them per test scenario,

                              we would need to make that configuration portable.

                               

                              ----

                               

                               

                              However, you are right, there are two use cases for Warp ftest:

                               

                              1. makes sure that the implementation doesn't break under certain conditions
                              2. shows the reference usage for particular scenarios

                               

                              We need to identify what is needed for Warp to meet (1) - one case is certainly handling redirects internally (aka CommandService).

                              This can be tested independently with an artificial test simulating redirected CommandService request.

                               

                              Given that the use case is complex, (2) doesn't appear to be implementable as part of functional test suite,

                              but we could create independent repository showing reference usage and including functional test.

                              and/or accompany it with a blog post on how to get Form authentication working with Warp.

                              • 12. Re: [warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication
                                brevilo Newbie

                                Lukáš Fryč wrote:

                                 

                                Note: the problem with the ftests are that they should be portable to various compliant application servers.

                                 

                                So even though we would be able to manage containers manually from ftest and configure them per test scenario,

                                we would need to make that configuration portable.

                                Exactly, hence my questions above :-)

                                 

                                FYI, I had a look around for potential solutions to this and Cargo seems like an interesting candidate. However, such an implementation seems like overkill for "just" a test case. What do you think?

                                Lukáš Fryč wrote:

                                 

                                1. makes sure that the implementation doesn't break under certain conditions
                                2. shows the reference usage for particular scenarios

                                 

                                1) I guess that one is going to be your's to implement (the artificial test simulating a redirected CommandService request)

                                2) I can certainly help out with this. I'll check my implementation against new snapshots as soon as they're available.

                                 

                                 

                                Cheers

                                • 13. Re: [warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication
                                  Lukáš Fryč Master

                                  Oliver Bock wrote:

                                  Lukáš Fryč wrote:

                                   

                                  1. makes sure that the implementation doesn't break under certain conditions
                                  2. shows the reference usage for particular scenarios

                                   

                                  1) I guess that one is going to be your's to implement (the artificial test simulating a redirected CommandService request)

                                  2) I can certainly help out with this. I'll check my implementation against new snapshots as soon as they're available.

                                   

                                   

                                  Cheers

                                   

                                  Hey Oliver,

                                   

                                  thanks to quick fix from Aris, the redirection should now be supported well + including test case: https://github.com/arquillian/arquillian-extension-warp/pull/16

                                   

                                  It's time to give it a try! :-)

                                  1 of 1 people found this helpful
                                  • 14. Re: [warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication
                                    brevilo Newbie

                                    Done :-) The redirect does seem to work but unfortunately we're not there yet. Have a look at ARQ-1365 for details...

                                    1 2 Previous Next