[warp] SynchronizationPoint$ServerResponseTimeoutException when using FORM authentication

[brevilo]

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

[lfryc]

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

[brevilo]

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!

[brevilo]

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

[lfryc]

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.

[brevilo]

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

[lfryc]

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.

[brevilo]

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

Cheers

[brevilo]

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

[lfryc]

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.

[brevilo]

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

[lfryc]

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.

[brevilo]

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

[lfryc]

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! :-)

[brevilo]

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