July 2012 - arquillian-issues - Jboss List Archives

[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

11 years, 11 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

11 years, 11 months

2
3
0 / 0

[JBoss JIRA] (ARQ-1010) Support for 'Guest/Nested' Containers

by Aslak Knutsen (JIRA)

Aslak Knutsen created ARQ-1010: ---------------------------------- Summary: Support for 'Guest/Nested' Containers Key: ARQ-1010 URL: https://issues.jboss.org/browse/ARQ-1010 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Base Implementation, Deployable Containers SPI Affects Versions: 1.0.1.Final Reporter: Aslak Knutsen The current Assumption is that the DeployalbeContainer is the final target. While that works great for ApplicationServers, there are cases where a Service running on the ApplicationServer is one of the Targets. e.g. a BPM Engine that runs on WLS/WAS/JBossAS etc but has it's own deployment mechanism for deploying the Process definitions. Currently we would have to create a DeployableContainer impl for each BPM+ContainerX combination to support Managed mode of the Host Container. In this case the BPM Container should be able to inherit configuration and depend upon the Host Container. e.g. Host runs on IP-X, BPM Container shouldn't need to be reconfigured with the Host IP by the user. When the Host is stopped, the BPM Container should be stopped first. The interesting usecase is where you have a BPM process that rely on Resources/Services in the Host Contianer. By having them linked you could deploy e.g. WebServices to the Host and Processes to the BPM that interact with the WebServices. -- 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

11 years, 11 months

1
2
0 / 0

[JBoss JIRA] (ARQ-1014) Instrumenation is skipped when the deployment is not testable

by Jan Papousek (JIRA)

Jan Papousek created ARQ-1014: --------------------------------- Summary: Instrumenation is skipped when the deployment is not testable Key: ARQ-1014 URL: https://issues.jboss.org/browse/ARQ-1014 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Jacoco Affects Versions: 1.0.0.Alpha3 Reporter: Jan Papousek Documentation of [Deployment|https://github.com/arquillian/arquillian-core/blob/master/cont... says: "Defines if this deployment should be wrapped up based on the protocol so the testcase can be executed incontainer.". However when it's set to false it also disables all [application archive processors|https://github.com/arquillian/arquillian-core/blob/master/cont...] (see [code|https://github.com/arquillian/arquillian-core/blob/master/container/...]), so Jacoco instrumentation is not processed. I think this behaviour should be at least well documented, but it would be better to rename testable() or change behaviour of deployment generator. -- 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

11 years, 11 months

2
2
0 / 0

[JBoss JIRA] (ARQ-1018) Remote extensions are not loaded when the deployment method is inside the test annotated by @RunAsClient annotation

by Jan Papousek (JIRA)

Jan Papousek created ARQ-1018: --------------------------------- Summary: Remote extensions are not loaded when the deployment method is inside the test annotated by @RunAsClient annotation Key: ARQ-1018 URL: https://issues.jboss.org/browse/ARQ-1018 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Base Implementation Affects Versions: 1.0.1.Final Reporter: Jan Papousek *Use Case* I want to test web application and use Arquillian Jacoco Extension to get code coverage. I have abstract test class of the following pattern (all tests extend this abstract class): {code} @RunAsClient public abstract class AbstractTest extends Arquillian { @Deployment public static WebArchive createTestArchive() { ... } ... } {code} *Problem* Because of the @RunAsClient annotation, the RemoteExtensionLoader is not called, so JacocoRemoteExtension is not loaded. -- 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

11 years, 11 months

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

11 years, 11 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

11 years, 11 months

3
2
0 / 0

[JBoss JIRA] (ARQ-1009) ClassNotFoundException when using CLEAN_INSERT

by Karsten Ohme (JIRA)

Karsten Ohme created ARQ-1009: --------------------------------- Summary: ClassNotFoundException when using CLEAN_INSERT Key: ARQ-1009 URL: https://issues.jboss.org/browse/ARQ-1009 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Configuration Affects Versions: persistence_1.0.0.Alpha4 Environment: Windows 7, Java 1.6.0_31 Reporter: Karsten Ohme I set in arquillian.xml the configuration property: <property name="dataSeedStrategy">CLEAN_INSERT</property> When starting the test I get a ClassNotFoundException in ConfigurationTypeConverter in line 182: Object instance = Class.forName(value).newInstance(); -- 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

11 years, 11 months

2
2
0 / 0

[JBoss JIRA] (ARQ-978) Provide Warp with extension for testing SpringMVC.

by Jakub Narloch (JIRA)

Jakub Narloch created ARQ-978: --------------------------------- Summary: Provide Warp with extension for testing SpringMVC. Key: ARQ-978 URL: https://issues.jboss.org/browse/ARQ-978 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Extension - Warp Reporter: Jakub Narloch Assignee: Jakub Narloch Fix For: warp_1.0.0.next Warp will be perfect platform for running the SpringMVC tests in the container. -- 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

11 years, 11 months

3
7
0 / 0

[JBoss JIRA] Created: (ARQ-219) Implement an embedded Spring container

by Dan Allen (JIRA)

Implement an embedded Spring container -------------------------------------- Key: ARQ-219 URL: https://jira.jboss.org/browse/ARQ-219 Project: Arquillian Issue Type: Feature Request Affects Versions: 1.0.0.Alpha2 Reporter: Dan Allen Implement an embedded container that bootstraps the Spring bean container and provides injection of Spring beans into the test class. This container will require classpath trickery (perhaps the ShrinkWrap classloader) to narrow the visibility of the scanner to classes in the test archive. -- 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

11 years, 11 months

3
13
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues July 2012