Uploaded image for project: 'Arquillian'
  1. Arquillian
  2. ARQ-153

Protocol configuration element should be separate from Container

        Details

          Description

          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.

          <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>

            Gliffy Diagrams

              Issue Links

              blocks

              Feature Request - A new feature of the product, which has yet to be developed. ARQ-196 Should support controlling multiple Containers

              • Minor - Minor loss of function, or other problem where easy workaround is present.
              • Closed

              Bug - A problem which impairs or prevents the functions of the product. ARQ-124 Move jndi.properties out as Configuration

              • Critical - An upcoming version that is affected by this issue cannot be released until it's addressed. A critical bug is one that crashes the application, causes loss of data or severe memory leak.
              • Closed

              Bug - A problem which impairs or prevents the functions of the product. ARQ-171 ServletMethodExecutor should get context path from container

              • Major - A request that should be considered seriously but is not a show stopper.
              • Closed
              relates to

              Feature Request - A new feature of the product, which has yet to be developed. ARQ-125 Prototype "ArquillianContext" Hook between test and the ARQ container

              • Major - A request that should be considered seriously but is not a show stopper.
              • Open

              Feature Request - A new feature of the product, which has yet to be developed. ARQ-223 Create a EJB test execution protocol

              • Major - A request that should be considered seriously but is not a show stopper.
              • Open

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                dan.j.allen Dan Allen added a comment -

                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.

                Show
                dan.j.allen Dan Allen added a comment - 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.
                Hide
                Permalink
                aslak Aslak Knutsen added a comment -

                The basis for ARQ-125 should provide that. With a option to open up for Enrichers of style:
                e.g.
                @ArquillianResource(MySerlvet.class)
                URL myServlet;

                Show
                aslak Aslak Knutsen added a comment - The basis for ARQ-125 should provide that. With a option to open up for Enrichers of style: e.g. @ArquillianResource(MySerlvet.class) URL myServlet;
                Hide
                Permalink
                kpiwko Karel Piwko added a comment -

                ARQ-215 implementation makes support of <xyz:protocol> in the same way as <abc:container> and <def:extension> for arquillian.xml a very small modification.

                Show
                kpiwko Karel Piwko added a comment - ARQ-215 implementation makes support of <xyz:protocol> in the same way as <abc:container> and <def:extension> for arquillian.xml a very small modification.
                Hide
                Permalink
                aslak Aslak Knutsen added a comment -

                true. one little extra detail to it..

                A Protocol should be associated with Container.

                So we have:

                <jboss:container>
                <http:protocol />
                </jboss:container>

                The ProtocolConfiguration is not a field on the ContainerConfiguration, but some higher level(Configuration?) should know how to match them..

                Show
                aslak Aslak Knutsen added a comment - true. one little extra detail to it.. A Protocol should be associated with Container. So we have: <jboss:container> <http:protocol /> </jboss:container> The ProtocolConfiguration is not a field on the ContainerConfiguration, but some higher level(Configuration?) should know how to match them..
                Hide
                Permalink
                dan.j.allen Dan Allen added a comment -

                I should mention for those following this issue that this will resolve the problem of Arquillian getting 404s when it deploys a WebArchive that isn't named test.war.

                Show
                dan.j.allen Dan Allen added a comment - I should mention for those following this issue that this will resolve the problem of Arquillian getting 404s when it deploys a WebArchive that isn't named test.war.
                Hide
                Permalink
                aslak Aslak Knutsen added a comment -

                https://github.com/aslakknutsen/arquillian/tree/the_bigger_picture

                Show
                aslak Aslak Knutsen added a comment - https://github.com/aslakknutsen/arquillian/tree/the_bigger_picture

                  People

                  • Assignee:
                    aslak Aslak Knutsen
                    Reporter:
                    aslak Aslak Knutsen
                  • Votes:
                    1 Vote for this issue
                    Watchers:
                    0 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved:

                      Development