February 2012 - arquillian-issues

[JBoss JIRA] (ARQ-689) Implement @BeforeDeploy (possibly as an extension)

by Ondrej Zizka (Created) (JIRA)

Implement @BeforeDeploy (possibly as an extension) -------------------------------------------------- Key: ARQ-689 URL: https://issues.jboss.org/browse/ARQ-689 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Base Implementation Affects Versions: 1.0.0.CR5 Reporter: Ondrej Zizka Assignee: Aslak Knutsen -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

4
4
0 / 0

[JBoss JIRA] (ARQ-705) @ShouldThrowException() - if expected deployment exception is not raised it will stop to invoke other deployments and any tests aren't processed at all

by Pavel Janousek (Created) (JIRA)

@ShouldThrowException() - if expected deployment exception is not raised it will stop to invoke other deployments and any tests aren't processed at all ------------------------------------------------------------------------------------------------------------------------------------------------------- Key: ARQ-705 URL: https://issues.jboss.org/browse/ARQ-705 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Pavel Janousek Let imagine class like:{code} @RunWith(Arquillian.class) public class ImagineTestCase { @Deployment(name="dep1") @ShouldThrowException(Exception.class) public static Archive<?> dep1() { ... } @Deployment(name="dep2") public static Archive<?> dep2() { ... } @Test @OperateOnDeployment("dep1") public void Test1() throws Exception { ... } @Test @OperateOnDeployment("dep2") public void Test2() throws Exception { ... } } {code} Present behavior - if exception isn't raised during deployment dep1 (and this is also the first deployment ARQ want to run), everything other is stopped, although deployment dep2 could work ok and Test2() depends only on dep2. It doesn't make sense for me, I prefer to continue run some tests if anyone is available and isn't blocked by failed deployment -> try to run dep2(), deploy produced artifact and invoke Test2, even dep1() failed (not raised Exception in this case). Do you agree with me? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

4
4
0 / 0

[JBoss JIRA] (ARQ-729) Do not replace TestNG provided method parameters with values from TestEnrichers

by Dan Spasojevic (JIRA)

Dan Spasojevic created ARQ-729: ---------------------------------- Summary: Do not replace TestNG provided method parameters with values from TestEnrichers Key: ARQ-729 URL: https://issues.jboss.org/browse/ARQ-729 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Test Harness Integration Affects Versions: 1.0.0.CR7 Environment: shrinkwrap 1.0.0-cr-1 arquillian 1.0.0.CR7 jboss AS 7 remote arquillian container 7.1.0CR1b testng 6.3.1 Reporter: Dan Spasojevic At the moment, Arquillian with always replace values provided by TestNG @DataProviders and [TestNG basic injection|http://testng.org/doc/documentation-main.html#dependency-injection] with values produced by TestEnricher+resolve(Method):Object[]. This means that test methods will not receive values produced by the @DataProvider if they are also produced by a TestEnricher. It would be desirable if enrichment was only done if too few values are provided by TestNG. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
1
0 / 0

[JBoss JIRA] (ARQ-733) ClientDeployer.deploy should return a boolean

by George Vagenas (JIRA)

George Vagenas created ARQ-733: ---------------------------------- Summary: ClientDeployer.deploy should return a boolean Key: ARQ-733 URL: https://issues.jboss.org/browse/ARQ-733 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Deployable Containers SPI Reporter: George Vagenas Priority: Optional In a unmanaged deployement where the ClientDeployer.deploy method is used to deploy the archive, the method should return a boolean to indicate success or failure of the deployment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
6
0 / 0

[JBoss JIRA] (ARQ-734) Filter TestClass based on @OperatesOnDeployment during deploy

by Aslak Knutsen (JIRA)

Aslak Knutsen created ARQ-734: --------------------------------- Summary: Filter TestClass based on @OperatesOnDeployment during deploy Key: ARQ-734 URL: https://issues.jboss.org/browse/ARQ-734 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Base Implementation Affects Versions: 1.0.0.CR7 Reporter: Aslak Knutsen When using Multiple incontainer Deployments with different Content in combination with @OperatesOnDeployment @Tests might fail due to CNFE. CNFE is thrown by the Container because the TestClass is refers to Classes from the 'other' deployment and can't be loaded, even tho they are not executed. Arquillian should Filter and Rewrite the TestClass before it is deployed so only the @Test methods that are targeted to a specific Deployment are visible runtime. Note: javaassist is a very common lib and version conflicts are easy to occur. Shard javassist under a org.jboss.arq namespace? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
2
0 / 0

[JBoss JIRA] (ARQ-738) Update integration Jacoco integration to 5.6 level

by Aslak Knutsen (JIRA)

Aslak Knutsen created ARQ-738: --------------------------------- Summary: Update integration Jacoco integration to 5.6 level Key: ARQ-738 URL: https://issues.jboss.org/browse/ARQ-738 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Extension - Jacoco Affects Versions: jacoco_1.0.0.Alpha2 Reporter: Aslak Knutsen Fix For: jacoco_1.0.0.next Jacoco API/SPI changed from 5.3 to 5.6. Need to update the Arquillian integration code to reflect the changes -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

3
9
0 / 0

[JBoss JIRA] Created: (ARQ-141) Add option to export the generated Archive to inspect the final deployment

by Aslak Knutsen (JIRA)

Add option to export the generated Archive to inspect the final deployment -------------------------------------------------------------------------- Key: ARQ-141 URL: https://jira.jboss.org/browse/ARQ-141 Project: Arquillian Issue Type: Task Components: Configuration, Documentation Reporter: Aslak Knutsen It is useful for debugging to have Arquillian export the Archive it is about to deploy, specially in IN_CONTAINER mode. Create a ArchiveExporter EventHandler on class level and make the export folder configurable. If option is not set: don't export -- 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

12 years, 1 month

4
10
0 / 0

[JBoss JIRA] Created: (ARQ-350) Map client events 1 to 1 with container events

by Aslak Knutsen (JIRA)

Map client events 1 to 1 with container events ---------------------------------------------- Key: ARQ-350 URL: https://issues.jboss.org/browse/ARQ-350 Project: Arquillian Issue Type: Feature Request Components: Base Implementation, Test Protocol SPIs and Implementation Reporter: Aslak Knutsen We should redo how the test execution lifecycles happen. In the current impl the flow is: Client(BeforSuite, BeforeClass, Before) -> Container(BeforSuite, BeforeClass, Before, Test, After, AfterClass, AfterSuite) -> Client(After, AfterClass, AfterSuite) We should map these 1 to 1 with the incontainer execution and keep the test instance alive between the calls. Client(BeforeClass) -> Container(BeforeClass) Client(Before) -> Container(Before) .. This way the execution is closer to how it normally would be, and extensions can interact with the Container/Environment or Client in the appropriate lifecycles more naturally. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
1
0 / 0

[JBoss JIRA] (ARQ-762) Add JBoss AS 4.2 and 5.1 containers to the test suite

by Bartosz Majsak (JIRA)

Bartosz Majsak created ARQ-762: ---------------------------------- Summary: Add JBoss AS 4.2 and 5.1 containers to the test suite Key: ARQ-762 URL: https://issues.jboss.org/browse/ARQ-762 Project: Arquillian Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Extension - Persistence Affects Versions: persistence_1.0.0.Alpha3 Reporter: Bartosz Majsak Assignee: Bartosz Majsak Fix For: persistence_1.0.0.next -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (ARQ-506) Support more complex property types in container configuration

by Gerhard Poul (JIRA)

Support more complex property types in container configuration -------------------------------------------------------------- Key: ARQ-506 URL: https://issues.jboss.org/browse/ARQ-506 Project: Arquillian Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Configuration Reporter: Gerhard Poul Priority: Optional It might sometimes be helpful to support arbitrary property lists within an arquillian configuration, such as when we want to make it possible to pass properties to the underlying container implementations, but that have no effect on the behavior of the arquillian-container-implementation itself. This is not to replace, but to augment the current configuration capability, such that we can provide something like the following in an arquillian.xml: <container qualifier="someQualifier" default="true"> <configuration> <propertyList name="somePropertyName"> <propertyEntry name="somePropertyEntryName" type="java.lang.String" value="someValue" /> <propertyEntry name="somePropertyEntryName2" type="java.lang.Integer" value="1234" /> ... </propertyList> <property name="someOtherProperty">someValue</property> </configuration> </container> -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

3
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues February 2012