[arquillian-issues] [JBoss JIRA] Commented: (ARQ-153) Protocol configuration element should be separate from Container

[Dan Allen (JIRA)]

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

Dan Allen commented on ARQ-153:
-------------------------------

When this feature is implemented, it would be nice to push these settings up into common configuration interfaces. This way, it would give the developer the ability to inject the container configuration so that the test knows how to communicate with the test archive deployed to the container.

For instance, consider we are testing a REST service.

@RunWith(Arquillian.class)
public class RESTEndpointTest {
   @Deployment
   public static Archive<?> createDeployment() { ... }

   @Arquillian ContainerContext containerContext;

   @Test
   public void shouldRespondToRequest() {
      ClientRequest request = new ClientRequest(containerContext.getApplicationUri() + "/resource/customer/1");
      ClientResponse<String> responseObj = request.get(String.class);
      Assert.assertEquals(200, responseObj.getStatus());
   }
} 

getApplicationUri() is a convenience method which puts together:

- remoteServerAddress (from servlet protocol)
- remoteServerHttpPort (from servlet protocol)
- deploymentContextPath (from container)

to get something like http://localhost:8080/test

It's nearly impossible to write HTTP client tests (JAX-RS, Selenium, etc) in a portable way w/o this feature.

> Protocol configuration element should be separate from Container
> ----------------------------------------------------------------
>
>                 Key: ARQ-153
>                 URL: https://jira.jboss.org/browse/ARQ-153
>             Project: Arquillian
>          Issue Type: Feature Request
>          Components: Configuration
>    Affects Versions: 1.0.0.Alpha2
>            Reporter: Aslak Knutsen
>             Fix For: 1.0.0.Beta1
>
>
> A Contianer should be able to run with any of the support Protocols for communication with TestCase running inside the container. This needs to be configurable in a common way.
> Currently Servlet Protocol configuration is stuck in the specific Containers who use it, this needs to be extracted.
> e.g.
> {code:XML}
> <arquillian xmlns="http://jboss.com/arquillian"
> 		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 		xmlns:jboss="urn:arq:org.jboss.arquillian.jbossas.remote60"
> 		xmlns:servlet="urn:arq:org.jboss.arquillian.protocol.servlet"
> 		xmlns:jmx="urn:arq:org.jboss.arquillian.protocol.jmx"
> 		xmlns:jndi="urn:arq:org.jboss.arquillian.jndi">
> 	<jboss:container id="jbossTest">
> 		<localDeploymentBindAddress>my.domain</localDeploymentBindAddress>
> 		<servlet:protocol>
> 			<remoteServerAddress>remote.server</remoteServerAddress>
> 			<remoteServerHttpPort>8181</remoteServerHttpPort>
> 		</servlet:protocol>
> 		<jndi:protocol> <!-- Is this really a Protocol in the Arquillian sense? -->
> 			<javaNamingProviderUrl>jnp://remote.server:1099</javaNamingProviderUrl>
> 			<javaNamingFactoryInitial>org.jnp.interfaces.NamingContextFactory</javaNamingFactoryInitial>
> 			<javaNamingFactoryUrlPkgs>org.jboss.naming\:org.jnp.interfaces</javaNamingFactoryUrlPkgs>
> 		</jndi:protocol>
> 	</jboss:container>	
> 	<jboss:container id="jbossStage">
> 		<localDeploymentBindAddress>my.domain</localDeploymentBindAddress>
> 		<jmx:protocol>
> 			<serviceUrl>service:jmx:rmi:///jndi/rmi://localhost:1099/</serviceUrl>
> 		</jmx:protocol>
> 		<jndi:protocol>
> 			<javaNamingProviderUrl>jnp://remote.server:1099</javaNamingProviderUrl>
> 			<javaNamingFactoryInitial>org.jnp.interfaces.NamingContextFactory</javaNamingFactoryInitial>
> 			<javaNamingFactoryUrlPkgs>org.jboss.naming\:org.jnp.interfaces</javaNamingFactoryUrlPkgs>
> 		</jndi:protocol>
> 	</jboss:container>	
> </arquillian>
> {code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira