May 2012 - arquillian-issues - Jboss List Archives

[JBoss JIRA] (ARQ-726) Arq doc: Missing note about -Darquillian.xml=some-file-or-classpath-resource.xml

by Ondrej Zizka (JIRA)

Ondrej Zizka created ARQ-726: -------------------------------- Summary: Arq doc: Missing note about -Darquillian.xml=some-file-or-classpath-resource.xml Key: ARQ-726 URL: https://issues.jboss.org/browse/ARQ-726 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 1.0.0.CR5 Reporter: Ondrej Zizka Assignee: Aslak Knutsen Priority: Minor http://docs.jboss.org/arquillian/reference/latest/en-US/html_single/ 4.4. Container configuration Missing these information: * the -Darquillian.xml=... sys prop * that it can be a path on classpath or filesystem * which of the above takes precedence -- 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

13 years, 8 months

2
2
0 / 0

[JBoss JIRA] (ARQ-862) manual containers not to be stopped in AfterClass

by Radoslav Husar (JIRA)

Radoslav Husar created ARQ-862: ---------------------------------- Summary: manual containers not to be stopped in AfterClass Key: ARQ-862 URL: https://issues.jboss.org/browse/ARQ-862 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 1.0.0.CR8 Reporter: Radoslav Husar Currently, all containers with manually managed life-cycle are shutdown after class. This makes all tests run very long. The solution is to leave the container lifecycle handling to the user which has to deal with non-deterministic order of the test class execution him/herself but ARQ should still do the work for stopping the still running containers in @AfterSuite. -- 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

13 years, 8 months

2
2
0 / 0

[JBoss JIRA] (ARQ-905) Provide SPI for filtering tests

by Dan Allen (JIRA)

Dan Allen created ARQ-905: ----------------------------- Summary: Provide SPI for filtering tests Key: ARQ-905 URL: https://issues.jboss.org/browse/ARQ-905 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Dan Allen Provide an SPI (or observer hook) for filtering the test classes. There are many reasons to filter which tests are run: * execution speed * available environment (e.g., based on target container, based on access to shared resource) * permitted exclusions (like in a TCK) * user story * deliverable * demo * security (whether running the test is allowed) * ... We can't think of all of them. That's why we should over an SPI to allow these possibilities to be explored. Currently, test filtering (or selection) is handled in a few different ways: * suite definition * groups * test plugin includes/excludes (e.g., Maven surefire) While these options can handle many of the cases, they are still very limiting, esp since they are static declarations. Imagine long lists of test classes or brow-wrinkling include/exclude logic. Let's give the developers the choice of how they want to implement filtering. We can then provide some nice options in the way of extensions. For instance, imagine a rule-based test filter extension. You can write rules in the Drools DSL to decide which tests to execute. This is very powerful for user story-based development and even contract deliverables. The filter should be able to inject various parts of the Arquillian runtime, including: * Current test class being processed * Active container class and configuration * Test archive The filter should be able to invoke an "ignore" or "skip" method to instruct Arquillian to skip running the test. -- 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

13 years, 8 months

2
4
0 / 0

[JBoss JIRA] (ARQ-906) Provide SPI for container configuration activation

by Dan Allen (JIRA)

Dan Allen created ARQ-906: ----------------------------- Summary: Provide SPI for container configuration activation Key: ARQ-906 URL: https://issues.jboss.org/browse/ARQ-906 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Dan Allen Activing container configuration right now is a real pain. It requires the user to manually correlate the choice of container adapter with the choice of container configuration. I propose that we offer an SPI for container configuration activation. We can then provide some nice options in the way of extensions for doing container selection. For example, an extension could match the qualifier name to the package name of the container implementation to decide which configuration to activate. It could read a mapping file that the user provides. Or it could use a remote registry. Anything is possible once this aspect of Arquillian is pluggable. And it will take the burden of selecting a container configuration off the developer. -- 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

13 years, 8 months

2
1
0 / 0

[JBoss JIRA] (ARQ-920) Support @Deployment on non-public member (method or field)

by Dan Allen (JIRA)

Dan Allen created ARQ-920: ----------------------------- Summary: Support @Deployment on non-public member (method or field) Key: ARQ-920 URL: https://issues.jboss.org/browse/ARQ-920 Project: Arquillian Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Dan Allen Priority: Minor I don't see a reason why we are forcing the @Deployment member (method or field) to be public. It's common to have non-public injection points, so it's reasonable to assume we can honor non-public members for defining a @Deployment as well. -- 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

13 years, 8 months

2
4
0 / 0

[JBoss JIRA] (ARQ-941) Make Exception.class default for @ShouldThrowException value attribute

by Dan Allen (JIRA)

Dan Allen created ARQ-941: ----------------------------- Summary: Make Exception.class default for @ShouldThrowException value attribute Key: ARQ-941 URL: https://issues.jboss.org/browse/ARQ-941 Project: Arquillian Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Base Implementation Reporter: Dan Allen Priority: Minor The annotation @ShouldThrowException is expressive enough to be understood as meaning a generic Exception will be thrown (during deployment) unless a more specific exception is specified. Therefore, a default should be specified for the value attribute such that: @ShouldThrowException == @ShouldThrowException(Exception.class) Here's the resulting annotation definition: {code:java} @Documented @Retention(RUNTIME) @Target(ElementType.METHOD) public @interface ShouldThrowException { Class<? extends Exception> value() default Exception.class; } {code} (Alternatively, the default can be Throwable.class, though the value of least surprise is likely Exception.class). -- 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

13 years, 8 months

2
2
0 / 0

[JBoss JIRA] (ARQ-947) Core: Define de-enrichers as counter-parts to enrichers

by Lukáš Fryč (JIRA)

Lukáš Fryč created ARQ-947: ------------------------------ Summary: Core: Define de-enrichers as counter-parts to enrichers Key: ARQ-947 URL: https://issues.jboss.org/browse/ARQ-947 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 1.0.0.Final Reporter: Lukáš Fryč Extension {{Warp}} handles de-enrichment by watching changes in enriched fields. But the implementation of de-enrichment could be specifically addressed for enricher implementations, thus being part of the {{Core}}. Additionally, enrichers might know how to unwrap the value so it can be serialized and transferred to client (this might be separate issue). -- 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

13 years, 8 months

2
3
0 / 0

[JBoss JIRA] (ARQ-918) Pick a better name for testable attribute on @Deployment annotation

by Dan Allen (JIRA)

Dan Allen created ARQ-918: ----------------------------- Summary: Pick a better name for testable attribute on @Deployment annotation Key: ARQ-918 URL: https://issues.jboss.org/browse/ARQ-918 Project: Arquillian Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Base Implementation Affects Versions: 1.0.0.Final Reporter: Dan Allen @Deployment(testable = false) sends the wrong message for a testing platform and is subject to a wide variety of interpretations. We need a better name for this attribute. The purpose of this attribute is to determine if this deployment should be wrapped up based on the protocol so the test case can be executed inside the container. I'd be content if we gave it a very explicit name, even if that name wasn't tremendously fluent. Here are some suggestions: * transportsTest : Indicates whether this deployment will transport the test as part of the deployment so the it can be executed inside the container * testRunner : Indicates whether this deployment is itself a test runner, which by definition means it will be run inside the container * providesTestRunner : Mixed mode tests are possible, so this most accurately indicates whether this deployment will provide an additional test runner inside the container * hostsTest : Indicates whether the deployment will be a host to the test, so the test can be run inside the container * packageWithTest : Indicates whether this deployment will be packaged with the test and deployed to the server; when false, the deployment is left alone (not packaged with test) The hard part is that when the test is run in container, the @Deployment archive, the test and the test infrastructure often go into another archive that's the real deployment. So this is more of a directive of how to handle the @Deployment than it is about what role it will serve directly. I think that "testRunner" or "providesTestRunner" are the most clear options of the ones listed above. We can support this attribute as an alias to maintain backwards compatibility, marking testable as deprecated. -- 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

13 years, 8 months

7
32
0 / 0

[JBoss JIRA] (ARQ-622) Support global configurationc

by Jozef Hartinger (Created) (JIRA)

Support global configurationc ----------------------------- Key: ARQ-622 URL: https://issues.jboss.org/browse/ARQ-622 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Configuration Affects Versions: 1.0.0.CR4 Reporter: Jozef Hartinger Fix For: 1.1.0.CR1 Similarly to the way Maven's settings.xml works, provide a global arquillian configuration file located e.g. in ~/.arquillian/arquillian.xml that could be used to configure global machine-specific configuration. This could include: * container-specific configuration like path to JBoss AS * credentials (e.g. openshift setup - see https://github.com/jharting/arquillian-container-openshift/blob/master/op... for an example) * ajocado setup - selenium settings like location of the browser * others... -- 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

13 years, 8 months

3
2
0 / 0

[JBoss JIRA] (ARQ-945) Extract Spring Integration out of Spring Deployer

by Aslak Knutsen (JIRA)

Aslak Knutsen created ARQ-945: --------------------------------- Summary: Extract Spring Integration out of Spring Deployer Key: ARQ-945 URL: https://issues.jboss.org/browse/ARQ-945 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Spring Integration Affects Versions: spring_1.0.0.Alpha1 Reporter: Aslak Knutsen Assignee: Marius Bogoevici Fix For: spring_1.0.0.next In Alpha1 the Service Deployer and the Service Integration is one module, these should be two separate where the Service Integration part can be reused between the Service Deployer and the upcoming Service Container Service Integration = Enrichers Service Deployer = Related to moving Spring to a Container (packaging) -- 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

13 years, 8 months

2
6
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues May 2012