[arquillian-issues] [JBoss JIRA] (ARQ-1365) Warp: CommandEventBus doesn't support (port) redirects

Thu Apr 4 18:24:42 EDT 2013

    [ https://issues.jboss.org/browse/ARQ-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765107#comment-12765107 ] 

Oliver Bock edited comment on ARQ-1365 at 4/4/13 6:23 PM:
----------------------------------------------------------

Hi guys, thanks for looking into this so quickly.

I tested snapshot {{1.0.0.Beta1-20130404.130631-118}} and it seems that the test now indeed survives the port redirect. However, I could only infer that result as the test now runs into a SSL-related exception. Please note: this exception is also thrown for client-side tests that previously worked with {{1.0.0.Alpha2}}, so this can still be considered a regression. I'll attach the Arquillian/VM debug log interleaved with the exception details (assuming they're time-correlated). FYI, I'm using a self-signed certificate which {{1.0.0.Alpha2}} didn't complain about. Maybe the current snapshot somehow looses the SSL context configured in JBoss' {{standalone.xml}}?

Update 1: I could make some progress in that I could get around the exception reported in the previously attached file by supplying {{-Djavax.net.ssl.trustStore=/path/to/local/keystore}} to the client VM. Now I'm getting an issue related to my [self-signed certificate|http://docs.jboss.org/jbossweb/7.0.x/ssl-howto.html]. Looking into it... Again, {{1.0.0.Alpha2}} and JBoss itself haven't complained about it so far, without passing VM properties that is.

Update 2: I found a solution to get rid of the certificate issue in update 1 ("missing" SAN or Subject Alternative Name) and now client-side tests work again - including port redirect and SSL. So, the primary issue is indeed resolved but it seems that Warp doesn't make use of JBoss's SSL context/config anymore.

Do we want to deal with this in this issue because it's a regression? Shall we make it part of ARQ-1366? Or shall we use a new issue entirely?

      was (Author: brevilo):
    Hi guys, thanks for looking into this so quickly.

I tested snapshot {{1.0.0.Beta1-20130404.130631-118}} and it seems that the test now indeed survives the port redirect. However, I could only infer that result as the test now runs into a SSL-related exception. Please note: this exception is also thrown for client-side tests that previously worked with {{1.0.0.Alpha2}}, so this can still be considered a regression. I'll attach the Arquillian/VM debug log interleaved with the exception details (assuming they're time-correlated). FYI, I'm using a self-signed certificate which {{1.0.0.Alpha2}} didn't complain about. Maybe the current snapshot somehow looses the SSL context configured in JBoss' {{standalone.xml}}?

Update: I could make some progress in that I could get around the exception reported in the previously attached file by supplying {{-Djavax.net.ssl.trustStore=/path/to/local/keystore}} to the client VM. Now I'm getting an issue related to my [self-signed certificate|http://docs.jboss.org/jbossweb/7.0.x/ssl-howto.html]. Looking into it... Again, {{1.0.0.Alpha2}} and JBoss itself haven't complained about it so far, without passing VM properties that is. The bottom line seems to be that Warp doesn't make use of JBoss's SSL context/config anymore.

Do we want to deal with this in this issue because it's a regression? Shall we make it part of ARQ-1366? Or shall we use a new issue entirely?

> Warp: CommandEventBus doesn't support (port) redirects
> ------------------------------------------------------
>
>                 Key: ARQ-1365
>                 URL: https://issues.jboss.org/browse/ARQ-1365
>             Project: Arquillian
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Extension - Warp
>    Affects Versions: warp_1.0.0.Beta1
>            Reporter: Oliver Bock
>            Assignee: Aris Tzoumas
>              Labels: redirect, ssl, warp
>             Fix For: warp_1.0.0.Alpha3
>
>         Attachments: ARQ-1365_1.txt
>
>
> When JBosss AS 7 is configured to redirect HTTP (port 8888) to HTTPS (8889) in standalone.xml (web subsystem) using:
> {noformat}
>             <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" redirect-port="8889"/>
>             <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">
>                 <ssl password="[Your_password_here]" session-timeout="900"/>
>             </connector>
> {noformat}
> All Warp tests (client- and server-side) fail like this when using 1.0.0.Beta1-SNAPSHOT (client-side tests do work with 1.0.0.Alpha2):
> {noformat}
> 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)
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira