May 2013 - arquillian-issues - Jboss List Archives

[JBoss JIRA] (ARQGRA-283) Create blog entry about Graphene vs WebDriver

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-283?page=com.atlassian.jira.plugin... ] Lukáš Fryč updated ARQGRA-283: ------------------------------ Sprint: Sprint for Alpha4 (was: Sprint for Alpha4, Sprint 1) > Create blog entry about Graphene vs WebDriver > --------------------------------------------- > > Key: ARQGRA-283 > URL: https://issues.jboss.org/browse/ARQGRA-283 > Project: Arquillian Graphene > Issue Type: Task > Components: doc > Reporter: Juraj Húska > Assignee: Juraj Húska > Fix For: 2.0.0.Alpha5 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Create blog entry about core differences between WebDriver and Graphene. It should summarize all Graphene features to promote them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1274) @EJB#lookup() support in EJBInjectionEnricher

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/ARQ-1274?page=com.atlassian.jira.plugin.s... ] Martin Kouba commented on ARQ-1274: ----------------------------------- {{arquillian-testenricher-ejb}} currently depends on EJB 3.1 API. So this should be changed as well. > @EJB#lookup() support in EJBInjectionEnricher > --------------------------------------------- > > Key: ARQ-1274 > URL: https://issues.jboss.org/browse/ARQ-1274 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 1.0.4.Final > > > No doubt the {{EJBInjectionEnricher}} deserves a major refactoring (ARQ-77, ARQ-836, ...). However in the mean time we could add {{@EJB#lookup()}} support. The reason is {{EJB#mappedName()}} should not be used in EJB 3.1 (it's product-specific), instead portable JNDI names and {{EJB#lookup()}} should be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1274) @EJB#lookup() support in EJBInjectionEnricher

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1274?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen reopened ARQ-1274: -------------------------------- This breaks EE4/EE5 Containers. EJB.lookup is not found in EJB 3. We need to add a reflection call. > @EJB#lookup() support in EJBInjectionEnricher > --------------------------------------------- > > Key: ARQ-1274 > URL: https://issues.jboss.org/browse/ARQ-1274 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 1.0.4.Final > > > No doubt the {{EJBInjectionEnricher}} deserves a major refactoring (ARQ-77, ARQ-836, ...). However in the mean time we could add {{@EJB#lookup()}} support. The reason is {{EJB#mappedName()}} should not be used in EJB 3.1 (it's product-specific), instead portable JNDI names and {{EJB#lookup()}} should be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1284) Open up ServletMethodExecutor for easier extension

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1284?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen resolved ARQ-1284. -------------------------------- Resolution: Done https://github.com/arquillian/arquillian-core/commit/8ae82aa541cd2ab82613... > Open up ServletMethodExecutor for easier extension > -------------------------------------------------- > > Key: ARQ-1284 > URL: https://issues.jboss.org/browse/ARQ-1284 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Test Protocol SPIs and Implementation > Affects Versions: 1.0.3.Final > Reporter: Aslak Knutsen > Fix For: 1.0.4.Final > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

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

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-941?page=com.atlassian.jira.plugin.sy... ] Aslak Knutsen updated ARQ-941: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 1.0.4.Final (was: 2.0.0.Beta1) Resolution: Done pushed upstream: https://github.com/arquillian/arquillian-core/commit/455fd072111d9e99e93f... > Make Exception.class default for value attribute on @ShouldThrowException > ------------------------------------------------------------------------- > > 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 > Labels: starter > Fix For: 1.0.4.Final > > > 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 For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-700) Properties in arquillian.xml should handle new lines (by trimming them)

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-700?page=com.atlassian.jira.plugin.sy... ] Aslak Knutsen resolved ARQ-700. ------------------------------- Assignee: Bartosz Majsak Fix Version/s: 1.0.4.Final Resolution: Done https://github.com/arquillian/arquillian-core/commit/2d5608afe04ee593be96... > Properties in arquillian.xml should handle new lines (by trimming them) > ------------------------------------------------------------------------ > > Key: ARQ-700 > URL: https://issues.jboss.org/browse/ARQ-700 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Configuration > Affects Versions: 1.0.0.CR6 > Reporter: Hardy Ferentschik > Assignee: Bartosz Majsak > Labels: starter > Fix For: 1.0.4.Final > > > When trying to add _javaVmArguments_ to _arquillian.xml_ in order to debug the container new lines in the property will cause the container start to fail. > For example, the following works: > {code} > <arquillian xmlns="http://jboss.org/schema/arquillian" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://jboss.org/schema/arquillian > http://jboss.org/schema/arquillian/arquillian_1_0.xsd"> > <engine> > <property name="deploymentExportPath">target/</property> > </engine> > <container qualifier="jboss" default="true"> > <protocol type="jmx-as7"> > <property name="executionType">REMOTE</property> > </protocol> > <configuration> > <property name="jbossHome">target/jboss-as-7.1.0.Beta1</property> > <property name="javaVmArguments">-Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=y -Xmx512m -XX:MaxPermSize=128m</property> > </configuration> > </container> > </arquillian> > {code} > whereas this fails: > {code} > <arquillian xmlns="http://jboss.org/schema/arquillian" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://jboss.org/schema/arquillian > http://jboss.org/schema/arquillian/arquillian_1_0.xsd"> > <engine> > <property name="deploymentExportPath">target/</property> > </engine> > <container qualifier="jboss" default="true"> > <protocol type="jmx-as7"> > <property name="executionType">REMOTE</property> > </protocol> > <configuration> > <property name="jbossHome">target/jboss-as-7.1.0.Beta1</property> > <property name="javaVmArguments"> > -Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=y -Xmx512m -XX:MaxPermSize=128m > </property> > </configuration> > </container> > </arquillian> > {code} > given that often people use auto-formatting for xml the parser should take care of this and trim the configuration value. Also the resulting exception for the case where the value is on a new line is very confusing: > {noformat} > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:180) > at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:78) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:198) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97) > 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > Caused by: java.util.concurrent.TimeoutException: Managed server was not started within [30] s > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:176) > ... 65 more > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1356) TestResult isn't updated correctly when TestNG is used

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1356?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen updated ARQ-1356: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 1.0.4.Final Resolution: Done https://github.com/arquillian/arquillian-core/commit/9ade3284fd84f06d999a... > TestResult isn't updated correctly when TestNG is used > ------------------------------------------------------ > > Key: ARQ-1356 > URL: https://issues.jboss.org/browse/ARQ-1356 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.0.3.Final > Environment: TestNG 6.1.1 > Reporter: Jan Papousek > Assignee: Jan Papousek > Fix For: 1.0.4.Final > > > When a test fails, the state of TestResult is still PASSED and therefore it can't be used in observer: > {code} > public class LifecycleObserver { > @Inject > private Instance<TestResult> result; > public void afterTest(@Observes After event) { > if (result.get().getStatus().equals(PASSED)) { > // something > } else { > // something else > } > } > } > {code} > The problem is [LocalTestExecutor|https://github.com/arquillian/arquillian-core/blob/mast...] updates the status to FAILED only if an [exception is thrown|https://github.com/arquillian/arquillian-core/blob/master/containe...], but [TestMethodExecutor|https://github.com/arquillian/arquillian-core/blob/mas...] from TestNG implemenation doesn't throw any exception when the test fails. It [memorizes it in ITestResult object|https://github.com/arquillian/arquillian-core/blob/master/testng/c...]. > I propose to throw an exception in [the end of test invocation|https://github.com/arquillian/arquillian-core/blob/master/test...], if the test fails. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1071) NullPointerException when timeout is set in @Test when using JUnit

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1071?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen updated ARQ-1071: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 1.0.4.Final Resolution: Done pushed upstream https://github.com/arquillian/arquillian-core/commit/cb733a27838737c88ef1... > NullPointerException when timeout is set in @Test when using JUnit > ------------------------------------------------------------------ > > Key: ARQ-1071 > URL: https://issues.jboss.org/browse/ARQ-1071 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.0.Final, 1.0.1.Final > Reporter: Rick-Rainer Ludwig > Fix For: 1.0.4.Final > > > When defining a timeout in @Test of JUnit Arquillian throws a NullPointerException: > {code} > java.lang.NullPointerException > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOfTimeout.java:62) > {code} > The code to reproduce this: > {code} > import org.jboss.arquillian.junit.Arquillian; > import org.junit.Test; > import org.junit.runner.RunWith; > @RunWith(Arquillian.class) > public class TestTimeout { > @Test(timeout = 3000) > public void test() throws Exception { > Thread.sleep(1000); > } > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-264) Create possibility to "inject" elements from frames

by Juraj Húska (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-264?page=com.atlassian.jira.plugin... ] Work on ARQGRA-264 started by Juraj Húska. > Create possibility to "inject" elements from frames > --------------------------------------------------- > > Key: ARQGRA-264 > URL: https://issues.jboss.org/browse/ARQGRA-264 > Project: Arquillian Graphene > Issue Type: Feature Request > Affects Versions: 2.0.0.Alpha3 > Reporter: Aliaksei Lahachou > Assignee: Juraj Húska > Fix For: 2.0.0.Alpha5 > > Original Estimate: 6 hours > Remaining Estimate: 6 hours > > I don't like how WebDriver works with frames. I have to constantly switch between frames, I cannot simply "inject" element from a specific frame. I would love to have something like the following: > {code:java} > @FindBy(id = "menuBar") > @InFrame(id = "header") > private MenuBarFragment menuBar; > {code} > In this case Graphene should switch to frame "header" before any operation on menuBar and switch back to previous frame after (today, I have to do it manually). It seems to me that it is not too complex to do it with Arquillian/Graphene - you only need one more interceptor. > Elements not annotated with @InFrame should work on current frame just as today. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1003) Warp: Request timeouts during server/proxy debugging

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1003?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated ARQ-1003: ---------------------------- Fix Version/s: warp_1.0.0.Alpha3 (was: warp_1.next) > Warp: Request timeouts during server/proxy debugging > ---------------------------------------------------- > > Key: ARQ-1003 > URL: https://issues.jboss.org/browse/ARQ-1003 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha1 > Reporter: Lukáš Fryč > Fix For: warp_1.0.0.Alpha3 > > > When debugging server code or code of proxy, the test time outs. > There should be flag indicating mode of debugging, which would turn off timeouts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues May 2013