January 2011 - arquillian-issues - Jboss List Archives

[JBoss JIRA] Created: (ARQ-265) Support injection of MC Beans in JBoss AS Containers

by Aslak Knutsen (JIRA)

Support injection of MC Beans in JBoss AS Containers ---------------------------------------------------- Key: ARQ-265 URL: https://jira.jboss.org/browse/ARQ-265 Project: Arquillian Issue Type: Feature Request Components: Jetty Containers Reporter: Aslak Knutsen Support use of @Inject from MC in TestCases Lookup Kernel and resolve beans, or install test case as a MCBean ? -- 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, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (ARQ-247) Using the tomcat 6 embedded profile, @AfterClass methods are called after each test and method dependencies don't work

by Adam Warski (JIRA)

Using the tomcat 6 embedded profile, @AfterClass methods are called after each test and method dependencies don't work ---------------------------------------------------------------------------------------------------------------------- Key: ARQ-247 URL: https://jira.jboss.org/browse/ARQ-247 Project: Arquillian Issue Type: Bug Components: Tomcat Containers Affects Versions: 1.0.0.Alpha3 Reporter: Adam Warski If there are dependent tests (@Test(dependsOnMethods = "...")), TestNG throws this exception: org.testng.TestNGException: TestClass.testBBB() is not allowed to depend on public void TestClass.testAAA() throws java.lang.Exception at org.testng.internal.MethodHelper.findMethodsNamed(MethodHelper.java:149) Moreover, @AfterClass methods are called after each test, and additionally after the whole class. Same with @BeforeClass. -- 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, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (ARQ-262) Add a Tomcat remote container

by Pete Muir (JIRA)

Add a Tomcat remote container ----------------------------- Key: ARQ-262 URL: https://jira.jboss.org/browse/ARQ-262 Project: Arquillian Issue Type: Feature Request Components: Tomcat Containers Affects Versions: 1.0.0.Alpha3 Reporter: Pete Muir -- 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, 10 months

3
13
0 / 0

[JBoss JIRA] Created: (ARQ-238) Create a DeployableContainer integration for JBoss AS 4.2

by Aslak Knutsen (JIRA)

Create a DeployableContainer integration for JBoss AS 4.2 --------------------------------------------------------- Key: ARQ-238 URL: https://jira.jboss.org/browse/ARQ-238 Project: Arquillian Issue Type: Feature Request Components: Documentation, JBoss Containers Reporter: Aslak Knutsen Create a implementation that can talk to JBoss AS 4.2.x -- 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, 10 months

4
17
0 / 0

[JBoss JIRA] Created: (ARQ-320) ServiceLoader should honor vetoed extension implementations

by Dan Allen (JIRA)

ServiceLoader should honor vetoed extension implementations ----------------------------------------------------------- Key: ARQ-320 URL: https://jira.jboss.org/browse/ARQ-320 Project: Arquillian Issue Type: Feature Request Affects Versions: 1.0.0.Alpha4 Reporter: Dan Allen Fix For: 1.0.0.Beta1 The current ServiceLoader implementation makes it difficult (if not impossible) to extend an SPI implementation and have it take precedence over an implementation already on the classpath. In other words, it discourages being able to use an implementation as a library dependency. The reason this happens is because the original implementation provides a ServiceLoader activation file under META-INF/services. This conflicts with the activation file used by the extended implementation in the case that Arquillian is looking for exactly one implementation. The only way to work around this at the moment is to copy all of the classes required by the original implementation into your own project, extend (or modify) the original implementation class, and package those classes with a service activation file. In effect, you have removed the original activation file and replaced it with your own. Clearly what is missing is a mechanism to veto the original implementation. You know you which implementation you want and which one you don't want. So, in the activation file you simply mark the original implementation as vetoed (to reverse the effect of it being specified as an implementation). An implementation class would be vetoed by prefixing it with a ! symbol. !org.jboss.arquillian.container.jbossas.remote_6.JBossASRemoteContainer com.acme.arquillian.container.jbossas.remote_6.AcmeJBossASRemoteContainer While this may seem very specific as you are referencing an implementation class, that's the whole point because your Java code is extending that class. It's about library reuse, so you don't have to import the entire package just to exclude the activation file. Frankly, I feel like this is a critical missing piece in the JDK ServiceLoader model in general. It's like providing a light switch that only turns on, not off. Or a radio button with only one option. Once you press it, you can't unpress it. -- 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, 11 months

3
7
0 / 0

[JBoss JIRA] Created: (ARQ-330) Container Reference for Weld EE Embedded use 1.0.1.SP1 in example, should be 1.1.0.Beta1

by Aslak Knutsen (JIRA)

Container Reference for Weld EE Embedded use 1.0.1.SP1 in example, should be 1.1.0.Beta1 ---------------------------------------------------------------------------------------- Key: ARQ-330 URL: https://jira.jboss.org/browse/ARQ-330 Project: Arquillian Issue Type: Bug Components: Documentation Affects Versions: 1.0.0.Alpha4 Reporter: Aslak Knutsen -- 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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (ARQ-310) Add a post-construct method to ContainerConfiguration

by Dan Allen (JIRA)

Add a post-construct method to ContainerConfiguration ----------------------------------------------------- Key: ARQ-310 URL: https://jira.jboss.org/browse/ARQ-310 Project: Arquillian Issue Type: Feature Request Components: Configuration Affects Versions: 1.0.0.Alpha4 Reporter: Dan Allen The ContainerConfiguration SPI should include a method that is invoked after all the properties have been set so that component properties can be calculated and perhaps validation can be performed. When you introduce a container-managed component type w/o a post-construct hook, it results in logic being performed in setter methods. We don't want that sort of thing. We want to keep it clean. public interface ContainerConfiguration { ContainerProfile getContainerProfile(); void afterPropertiesSet(); // alternate: void postConstruct(); } We could also entertain the possibility of honoring the @PostConstruct annotation. An example use case is to assemble the JSR-88 deployment URI from various facts provided, such as the server host and port (or admin server host and port), if an explicit deployment URI is not provided. -- 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, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (ARQ-288) Document how to integration Arquillian into non-Maven builds (build integration chapter)

by Dan Allen (JIRA)

Document how to integration Arquillian into non-Maven builds (build integration chapter) ---------------------------------------------------------------------------------------- Key: ARQ-288 URL: https://jira.jboss.org/browse/ARQ-288 Project: Arquillian Issue Type: Task Components: Documentation Affects Versions: 1.0.0.Alpha4 Reporter: Dan Allen Fix For: 1.0.0.Beta1 There is a misconception spreading that Arquillian can only be used from a Maven. We need a build integration chapter to clarify the message that Arquillian is build-independent. The chapter should describe in general how Arquillian is hooked into a build system, then provide tutorials for Ant and Gradle. -- 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, 11 months

2
9
0 / 0

[JBoss JIRA] Created: (ARQ-50) research an alternative approach to inheriting from Arquillian base class in TestNG

by Dan Allen (JIRA)

research an alternative approach to inheriting from Arquillian base class in TestNG ----------------------------------------------------------------------------------- Key: ARQ-50 URL: https://jira.jboss.org/jira/browse/ARQ-50 Project: Arquillian Issue Type: Feature Request Affects Versions: 1.0.0-alpha-1 Reporter: Dan Allen Priority: Minor This issue is a research and development task to determine if there is an alternative approach that can be used, rather than inheriting from the Arquillian base class, to hook a TestNG test into the Arquillian functionality. JUnit offers a @RunWith annotation which is what the JUnit module uses. The closest hook TestNG seems to offer is the ITestListener interface. However, the question becomes, how does that map to the requirements: @BeforeSuite -> start container (~ ITestListener.onStart) @BeforeClass -> deploy (??) TestMethod/IHookable -> remote call (??) @AfterClass -> undeploy -> (??) @AfterSuite -> stop container -> (~ ITestListener.onFinish) There was discussion on this thread about supporting @RunWith in TestNG: http://markmail.org/message/fxm6bddk6wzqa4yp -- 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

12 years, 11 months

4
14
0 / 0

[JBoss JIRA] Created: (ARQ-287) Add support for filtering tests based on required execution environment

by Dan Allen (JIRA)

Add support for filtering tests based on required execution environment ----------------------------------------------------------------------- Key: ARQ-287 URL: https://jira.jboss.org/browse/ARQ-287 Project: Arquillian Issue Type: Feature Request Components: Configuration Affects Versions: 1.0.0.Alpha4 Reporter: Dan Allen Assignee: Dan Allen Fix For: 1.0.0.Beta1 Allow the developer to declaratively specify the execution environment required for a given test to function. Then, Arquillian should filter out tests that require an execution environment that the target container doesn't provide. (In other words, only execute a test case if the target container provides the execution environment the test requires). To support this feature, we need to introduce the concept of an execution environment definition into the API and a mechanism for indicating which containers provide a given execution environment. The developer experience will be something like: @RunWith(Arquillian.class) @RequiresJavaEE6 public class MyTestCase { ... } or @RunWith(Arquillian.class) @RequiresEnvironment(JavaEE6Container.class) public class MyTestCase { ... } Formal proposals and prototypes will be submitted as branches in github. -- 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, 11 months

2
11
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues January 2011