March 2011 - arquillian-issues - Jboss List Archives

[JBoss JIRA] Created: (ARQ-171) ServletMethodExecutor should get context path from container

by Dan Allen (JIRA)

ServletMethodExecutor should get context path from container ------------------------------------------------------------ Key: ARQ-171 URL: https://jira.jboss.org/browse/ARQ-171 Project: Arquillian Issue Type: Bug Components: Test Protocol SPIs and Implementation Affects Versions: 1.0.0.Alpha2 Reporter: Dan Allen While working on the JSR 88 container implementation, I noticed that ServletMethodExecutor is using the hard-coded context path "/test" to communicate with the application to invoke the ArquillianServletRunner. I think that the context path is something that the container implementation should be passing to the ServletMethodExecutor in the deploy() method. This assumption poses a particular problem in the JSR 88 container. When a WAR is deployed using JSR 88, the module is assigned a random name, and hence a random context path. Since there is no way to override the context path "/test" used by the ServletMethodExecutor, it fails to communicate with the server. The ServletMethodExecutor constructor should be changed to take the context path as the second parameter. All the container implementations will need to be updated accordingly. -- 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

15 years

2
6
0 / 0

[JBoss JIRA] Created: (ARQ-392) impl-base does not export resolver-maven-impl dep

by Aslak Knutsen (JIRA)

impl-base does not export resolver-maven-impl dep ------------------------------------------------- Key: ARQ-392 URL: https://issues.jboss.org/browse/ARQ-392 Project: Arquillian Issue Type: Bug Components: Base Implementation Reporter: Aslak Knutsen Assignee: Aslak Knutsen Fix For: 1.0.0.Alpha5 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

1
2
0 / 0

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

by Aslak Knutsen (JIRA)

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

15 years

3
10
0 / 0

[JBoss JIRA] Created: (ARQ-362) @Run(AS_CLIENT) support on @Test

by Aslak Knutsen (JIRA)

@Run(AS_CLIENT) support on @Test -------------------------------- Key: ARQ-362 URL: https://issues.jboss.org/browse/ARQ-362 Project: Arquillian Issue Type: Feature Request Components: Base Implementation, Test Harness Integration Reporter: Aslak Knutsen With support for multiple testable deployments and control off lifecycle method execution, we should open for: @Run() on @Test methods, to override a single test method targeted against a testable deployment to be executed on the client side. @Run() on @BeforeClass/@AfterClass/@Before/@After to support lifecycle methods both on client and incontainer. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

1
4
0 / 0

[JBoss JIRA] Created: (ARQ-313) ARQ should support Multi-module (Multiple WAR deployments) testing

by Lincoln Baxter III (JIRA)

ARQ should support Multi-module (Multiple WAR deployments) testing ------------------------------------------------------------------ Key: ARQ-313 URL: https://jira.jboss.org/browse/ARQ-313 Project: Arquillian Issue Type: Feature Request Components: Packaging Enricher SPI Reporter: Lincoln Baxter III It would be useful if you could return multiple deployments, potentially as a list of archives, and then run tests either AS_CLIENT that would interact against all deployments (however the container handles them,) or run with one deployment as the primary and run tests in IN_CONTAINER from the perspective of that WAR. This would effectively allow testing of multi-module WAR deployments or large-scale applications that are broken up under different ServletContexts. -- 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

15 years

2
5
0 / 0

[JBoss JIRA] Created: (ARQ-110) RunMode Local should reuse protocol-local

by Aslak Knutsen (JIRA)

RunMode Local should reuse protocol-local ----------------------------------------- Key: ARQ-110 URL: https://jira.jboss.org/jira/browse/ARQ-110 Project: Arquillian Issue Type: Task Reporter: Aslak Knutsen Currently the RunMode Local handler has it's own v. of the LocalMethodExecutor. The same code should be shared between the standalone containers(weld, openwebbeans, openejb...) options: - remove protocol-local and replace it with a class in impl? - remove protocol-local and replace it with a class in spi? - make impl depend on protocol-local ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

1
6
0 / 0

[JBoss JIRA] Created: (ARQ-158) Replace method arguments with toString instead of Class

by Aslak Knutsen (JIRA)

Replace method arguments with toString instead of Class ------------------------------------------------------- Key: ARQ-158 URL: https://jira.jboss.org/browse/ARQ-158 Project: Arquillian Issue Type: Feature Request Components: Test Harness Integration Affects Versions: 1.0.0.Alpha2 Reporter: Aslak Knutsen When using Argument injection in TestNG, TestNG tries to write out the values as part of the Report after all contexts are closed. In Alpha-2 we replace all arguments with Class after the test is executed. Replace the arguments with toString instead, this way the user can control what is written. -- 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

15 years

1
5
0 / 0

[JBoss JIRA] Created: (ARQ-379) Arquillian does not allow any configuration of OpenEJB

by David Allen (JIRA)

Arquillian does not allow any configuration of OpenEJB ------------------------------------------------------ Key: ARQ-379 URL: https://issues.jboss.org/browse/ARQ-379 Project: Arquillian Issue Type: Bug Components: OpenEJB Containers Affects Versions: 1.0.0.Alpha4 Reporter: David Allen Priority: Blocker The OpenEJBContainer in Arquillian only starts a couple basic services with OpenEJB without any configuration or addition of other services and resource adapters. Without Arquillian, one would use a jndi.properties file, for instance, and then create the initial context which would start OpenEJB with all of its configuration options. Without configuration, Arquillian tests cannot be used in real environments. As an example, consider the arquillian-samples/jpalab. When Maven is run with the default profile for OpenEJB and OpenJPA, the following log output is produced (excerpt with only OpenEJB startup lines): INFO - Configuring Service(id=Default Transaction Manager, type=TransactionManager, provider-id=Default Transaction Manager) INFO - Configuring Service(id=Default Security Service, type=SecurityService, provider-id=Default Security Service) INFO - Configuring enterprise application: /tmp/b99ee272-36b3-4d8c-a76a-379064eb1d62/81778d28-0e83-44b5-aecc-ced777c397a6.jar INFO - Configuring Service(id=Default Stateless Container, type=Container, provider-id=Default Stateless Container) INFO - Auto-creating a container for bean JavaPersistenceHelperBean: Container(type=STATELESS, id=Default Stateless Container) INFO - Configuring Service(id=Default Stateful Container, type=Container, provider-id=Default Stateful Container) INFO - Auto-creating a container for bean RepositoryBean: Container(type=STATEFUL, id=Default Stateful Container) INFO - Configuring PersistenceUnit(name=test) INFO - Configuring Service(id=Default JDBC Database, type=Resource, provider-id=Default JDBC Database) INFO - Auto-creating a Resource with id 'Default JDBC Database' of type 'DataSource for 'test'. INFO - Configuring Service(id=Default Unmanaged JDBC Database, type=Resource, provider-id=Default Unmanaged JDBC Database) INFO - Auto-creating a Resource with id 'Default Unmanaged JDBC Database' of type 'DataSource for 'test'. INFO - Adjusting PersistenceUnit test <jta-data-source> to Resource ID 'Default JDBC Database' from 'testDatabase' INFO - Adjusting PersistenceUnit test <non-jta-data-source> to Resource ID 'Default Unmanaged JDBC Database' from 'null' INFO - Enterprise application "/tmp/b99ee272-36b3-4d8c-a76a-379064eb1d62/81778d28-0e83-44b5-aecc-ced777c397a6.jar" loaded. INFO - Assembling app: /tmp/b99ee272-36b3-4d8c-a76a-379064eb1d62/81778d28-0e83-44b5-aecc-ced777c397a6.jar INFO - PersistenceUnit(name=test, provider=org.apache.openjpa.persistence.PersistenceProviderImpl) ERROR - JAVA AGENT NOT INSTALLED. The JPA Persistence Provider requested installation of a ClassFileTransformer which requires a JavaAgent. See http://openejb.apache.org/3.0/javaagent.html INFO - Jndi(name=JavaPersistenceHelperBeanLocal) --> Ejb(deployment-id=JavaPersistenceHelperBean) INFO - Jndi(name=RepositoryBeanLocal) --> Ejb(deployment-id=RepositoryBean) INFO - Created Ejb(deployment-id=JavaPersistenceHelperBean, ejb-name=JavaPersistenceHelperBean, container=Default Stateless Container) INFO - Created Ejb(deployment-id=RepositoryBean, ejb-name=RepositoryBean, container=Default Stateful Container) INFO - Deployed Application(path=/tmp/b99ee272-36b3-4d8c-a76a-379064eb1d62/81778d28-0e83-44b5-aecc-ced777c397a6.jar) The key items to look at is that only a "Default JDBC Database" data source and its unmanaged complement are created. There is no testDatabase data source being defined, as specified in the jndi.properties file. Also note that the persistence unit was automatically modified to point to the default data source since OpenEJB could not find any testDatabase source. I'll show what the log should look like shortly. I have this fixed already and in use on a project. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

2
8
0 / 0

[JBoss JIRA] Created: (ARQ-152) Support multiple container configurations for same container type

by Aslak Knutsen (JIRA)

Support multiple container configurations for same container type ----------------------------------------------------------------- Key: ARQ-152 URL: https://jira.jboss.org/browse/ARQ-152 Project: Arquillian Issue Type: Feature Request Components: Configuration Reporter: Aslak Knutsen Configuration need to support multiple container configurations for the same container type with a runtime 'flag' for switching configuration. UseCase: Different configuration for test/stage servers. 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"> <jboss:container id="jbossTest"> <localDeploymentBindAddress>my.domain</localDeploymentBindAddress> <remoteServerAddress>remote.test.server</remoteServerAddress> <remoteServerHttpPort>8080</remoteServerHttpPort> </jboss:container> <jboss:container id="jbossStage"> <localDeploymentBindAddress>my.domain</localDeploymentBindAddress> <remoteServerAddress>remote.stage.server</remoteServerAddress> <remoteServerHttpPort>8181</remoteServerHttpPort> </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

15 years

2
6
0 / 0

[JBoss JIRA] Created: (ARQ-371) Split Arquillian Selenium configuration according to framework

by Karel Piwko (JIRA)

Split Arquillian Selenium configuration according to framework -------------------------------------------------------------- Key: ARQ-371 URL: https://issues.jboss.org/browse/ARQ-371 Project: Arquillian Issue Type: Task Components: Extension - Selenium Reporter: Karel Piwko Assignee: Karel Piwko Fix For: 1.0.0.Beta1 There is no reason to have bloated configuration api...instead provide a way how each instantiator retrieves its own configuration which is tailored...e.g. no concept of wait types for ordinary Selenium, but they are needed for Ajocado. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

2
4
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues March 2011