October 2011 - arquillian-issues - Jboss List Archives

[JBoss JIRA] Created: (ARQ-556) Allow Arquillian to be used without writing Java code, for XML-based tools like Canoo WebTest

by Richard Kennard (JIRA)

Allow Arquillian to be used without writing Java code, for XML-based tools like Canoo WebTest --------------------------------------------------------------------------------------------- Key: ARQ-556 URL: https://issues.jboss.org/browse/ARQ-556 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Richard Kennard Hi guys, Thanks for all your hard work on Arquillian! I have a small feature request: At present Arquillian has a rather 'programmatic' API: you have to write Java code to do anything. This works great for ShrinkWrap, JUnit, HtmlUnit etc (ie. testing CDI, EJB, JMS etc). But it doesn't work so well for non-Java-code tools such as Canoo WebTest (ie. testing JSF). In order to support Canoo WebTest, Arquillian should be able to deploy/start/stop the server purely from Maven. Then I can use maven-webtest-plugin to run my webtest.xml (purely from Maven) and I'm done! I find testing XHTML output using an XML-based testing framework good because there is a lower 'impedence mismatch' than when using Java-code to test XHTML output. At present I'm able to get what I want using jboss-maven-plugin. It closely mirrors tomcat-maven-plugin and jetty-maven-plugin, which is great. However: 1. I have to use a fragile 'sleep' to wait until my app has deployed (see http://jira.codehaus.org/browse/MJBOSS-61) 2. jboss-maven-plugin appears to be unsupported (hasn't been updated to support AS 6 or 7) So I'd really like to see Arquillian supersede in this space? There is this: https://github.com/arquillian/arquillian-maven, but apparently it isn't able to act quite like jboss-maven-plugin can (http://community.jboss.org/message/622128#622128)? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
6
0 / 0

[JBoss JIRA] Created: (ARQ-376) Environment configuration is overridden by arquillian.xml

by Karel Piwko (JIRA)

Environment configuration is overridden by arquillian.xml --------------------------------------------------------- Key: ARQ-376 URL: https://issues.jboss.org/browse/ARQ-376 Project: Arquillian Issue Type: Bug Components: Configuration, JBoss Containers Affects Versions: 1.0.0.Beta1 Reporter: Karel Piwko Priority: Blocker It is not possible to define JAVA_HOME and JBOSS_HOME for managed containers via system properties because these values are used only during configuration creation and they will be overridden by arquillian.xml value. This is not desired behaviour how to make test execution flexible enough. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

3
6
0 / 0

[JBoss JIRA] Created: (ARQ-518) Support @PersistenceContet injection in weld-ee mock container

by Michal Huniewicz (JIRA)

Support @PersistenceContet injection in weld-ee mock container -------------------------------------------------------------- Key: ARQ-518 URL: https://issues.jboss.org/browse/ARQ-518 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Weld Containers Reporter: Michal Huniewicz I'd like weld-ee container to inject @PersistenceContext. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

3
5
0 / 0

[JBoss JIRA] (ARQ-620) arquillian-core-impl-base needs a non-optional dependency on jboss-logmanager

by Geoffrey De Smet (Created) (JIRA)

arquillian-core-impl-base needs a non-optional dependency on jboss-logmanager ----------------------------------------------------------------------------- Key: ARQ-620 URL: https://issues.jboss.org/browse/ARQ-620 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Geoffrey De Smet Priority: Optional Otherwise LoadableExtensionLoader fails with a ClassNotFoundException if you're deploying to jetty 6 for example (which doesn't have jboss-logging in it's classpath by default): {code} Could not load Logmanager "org.jboss.logmanager.LogManager" java.lang.ClassNotFoundException: org.jboss.logmanager.LogManager at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.util.logging.LogManager$1.run(LogManager.java:166) at java.security.AccessController.doPrivileged(Native Method) at java.util.logging.LogManager.<clinit>(LogManager.java:156) at java.util.logging.Logger.getLogger(Logger.java:287) at org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader.<clinit>(LoadableExtensionLoader.java:45) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at org.jboss.arquillian.test.spi.SecurityActions.loadClass(SecurityActions.java:64) at org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder.build(TestRunnerAdaptorBuilder.java:49) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:72) at org.junit.runner.JUnitCore.run(JUnitCore.java:157) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:71) at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:199) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) {code} -- 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, 5 months

2
3
0 / 0

[JBoss JIRA] (ARQ-639) Add ability to postpone initialization of non-managed deployments annotated @Deployment(managed=false)

by Dominik Pospisil (Created) (JIRA)

Add ability to postpone initialization of non-managed deployments annotated @Deployment(managed=false) ------------------------------------------------------------------------------------------------------ Key: ARQ-639 URL: https://issues.jboss.org/browse/ARQ-639 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 1.0.0.CR5 Reporter: Dominik Pospisil Currently deployments annotated using @Deployment(managed=false) are initialized prior to test case execution (EventTestRunnerAdaptor.beforeClass:80). Some test scenarios require that the initialization of the deployment is postponed until the actual deployment is performed using Deployer.deploy() call. It would be nice if the @Deploymnent(managed=false) method is called during Deployer.deploy() call by default or if there is an option to specify when the initialization should be performed. This way the content of the deployment may be constructed / updated during test case runtime using information which may not be available before test execution. -- 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, 5 months

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

12 years, 5 months

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

12 years, 5 months

3
13
0 / 0

[JBoss JIRA] Created: (ARQ-293) Support container targeted deployments

by Aslak Knutsen (JIRA)

Support container targeted deployments -------------------------------------- Key: ARQ-293 URL: https://jira.jboss.org/browse/ARQ-293 Project: Arquillian Issue Type: Feature Request Reporter: Aslak Knutsen Fix For: 1.0.0.CR1 in some cases it is useful to be able to define different @Deployments pr target container. e.g. Container X needs a different defined deployment descriptor to work etc.. -- 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, 6 months

3
9
0 / 0

[JBoss JIRA] Created: (ARQ-578) Create a Extension for handling Server State assertion during normal Servlet/JSF requests

by Aslak Knutsen (JIRA)

Create a Extension for handling Server State assertion during normal Servlet/JSF requests ----------------------------------------------------------------------------------------- Key: ARQ-578 URL: https://issues.jboss.org/browse/ARQ-578 Project: Arquillian Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Aslak Knutsen The general requirements would be: * hook into existing lifecycle callbacks from server (after_render, request_destory) * inject and assert on state during request in container ** we want this to happen during request so all state is still available (@RequestScope) * assert on output on client side ** this limits the need for incontianer deps / packaging Rough API idea/draft: https://gist.github.com/1184904 If we can piggyback the ServerState Assertion object to 'any' HTML request, we should be able to reuse existing tools for client testing like htmlunit / selenium, but with incontainer assertions. This could be JSFUnit 3+ combined with a Serlvet Extension. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (ARQ-355) Support fluent API and @DeploymentTarget for Rules

by Aslak Knutsen (JIRA)

Support fluent API and @DeploymentTarget for Rules -------------------------------------------------- Key: ARQ-355 URL: https://issues.jboss.org/browse/ARQ-355 Project: Arquillian Issue Type: Feature Request Components: Extension - Byteman Reporter: Aslak Knutsen Priority: Minor With multi container support in arquillian, the byteman integration should support @DeploymentTarget for specifying which container a rule should be deployed on. Byteman integration could follow the ShrinkWrap fluent API and make a API for rule creation, instead of having it only declarative via Annotaitons. @BMRule @DeploymentTarget("name") public static Rule createExceptionRule() { return Byteman.rule()..... } -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues October 2011