June 2015 - arquillian-issues - Jboss List Archives

[JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one

by Pëtr Andreev (JIRA)

[ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.s... ] Pëtr Andreev commented on ARQ-1952: ----------------------------------- @[~Lukáš Fryč] concerning ??we would tie Graphene implementation to Warp's internals??- I don`t get it at all- my intention was clearly decouple the [Customizable|https://github.com/petrandreev/arquillian-graphene/blob/ARQ-...] from anything else, even from the ARQ core` URLProvider, not to speak of the Warp. From my point of view the CustomizableURLResourceProvider is only useful in the narrow scope of "deploymentless" environment (which is rather a seldom use case) and should only take care of this not more and not less. The other thing is, that the proposed solution actually requires the rethinking of the _Provider_ concept in the way that _canProvide_ not just means one can provide instances of class but furthermore considers the current test/arquillian environment. Changing concepts could be risky though... The ResourceWapper draft would not work with the current core implementation as far as i could evaluate it, i guess for this the core provider handling should be re-factored a little. Just my two cents (i just don`t want the RF guys to throw out the Warp tests)... > Warp requests hit the application port instead of LittleProxy`s one > ------------------------------------------------------------------- > > Key: ARQ-1952 > URL: https://issues.jboss.org/browse/ARQ-1952 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 > Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 > Reporter: Pëtr Andreev > Assignee: Lukáš Fryč > Fix For: warp_1.0.0.Beta1 > > Attachments: ARQ-1952-failure.log, ARQ-1952-success.log > > > Warp observer intermittently fails while inspecting the requests with: > "There were no requests matched by observer \[containsParameter(XXXX)\] ". > The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated ARQ-1952: ---------------------------- Fix Version/s: warp_1.0.0.Beta1 > Warp requests hit the application port instead of LittleProxy`s one > ------------------------------------------------------------------- > > Key: ARQ-1952 > URL: https://issues.jboss.org/browse/ARQ-1952 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 > Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 > Reporter: Pëtr Andreev > Assignee: Lukáš Fryč > Fix For: warp_1.0.0.Beta1 > > Attachments: ARQ-1952-failure.log, ARQ-1952-success.log > > > Warp observer intermittently fails while inspecting the requests with: > "There were no requests matched by observer \[containsParameter(XXXX)\] ". > The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč reassigned ARQ-1952: ------------------------------- Assignee: Lukáš Fryč > Warp requests hit the application port instead of LittleProxy`s one > ------------------------------------------------------------------- > > Key: ARQ-1952 > URL: https://issues.jboss.org/browse/ARQ-1952 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 > Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 > Reporter: Pëtr Andreev > Assignee: Lukáš Fryč > Attachments: ARQ-1952-failure.log, ARQ-1952-success.log > > > Warp observer intermittently fails while inspecting the requests with: > "There were no requests matched by observer \[containsParameter(XXXX)\] ". > The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on ARQ-1952: --------------------------------- Thanks guys for great feedback. [~pjotrovsky] your solution would work, unfortunately it would mean we would tie Graphene implementation to Warp's internals. [~aslak] {{ResourceProviderWrapper}} is a way to go in a long term. As a workaround, one can create own project-specific locally that would enforce service `.override(..)` (in alphas it seems as appropriate workaround). ---- I must apologize for not reaching you sooner - my incorrectly setup mail filter was hiding the whole conversation from me! :-( > Warp requests hit the application port instead of LittleProxy`s one > ------------------------------------------------------------------- > > Key: ARQ-1952 > URL: https://issues.jboss.org/browse/ARQ-1952 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 > Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 > Reporter: Pëtr Andreev > Attachments: ARQ-1952-failure.log, ARQ-1952-success.log > > > Warp observer intermittently fails while inspecting the requests with: > "There were no requests matched by observer \[containsParameter(XXXX)\] ". > The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1952) Warp requests hit the application port instead of LittleProxy`s one

by Pavol Pitonak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1952?page=com.atlassian.jira.plugin.s... ] Pavol Pitonak commented on ARQ-1952: ------------------------------------ [~lfryc], could you please provide some feedback on this issue? > Warp requests hit the application port instead of LittleProxy`s one > ------------------------------------------------------------------- > > Key: ARQ-1952 > URL: https://issues.jboss.org/browse/ARQ-1952 > Project: Arquillian > Issue Type: Bug > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha7, warp_1.0.0.Beta1 > Environment: Linux x64, ChromeDriver , PhantomJSDriver, Wildfly 8.0 & 8.2, Mojarra 2.8 & 2.11 > Reporter: Pëtr Andreev > Attachments: ARQ-1952-failure.log, ARQ-1952-success.log > > > Warp observer intermittently fails while inspecting the requests with: > "There were no requests matched by observer \[containsParameter(XXXX)\] ". > The technical reason for the failure is that the client request hits the original (application server) port and not the [LittleProxy`s|https://github.com/adamfisk/LittleProxy] one (HTTP successful and failed traffic is attached showing the HTTP requests going to the wrong port, i.e 8080). Since Warp hooks into the client/server conversation providing its own implementation of _HttpFiltersSourceAdapter_ in _DefaultHttpFiltersSource_, while expecting the payload request from client after setting up a WarpContext, the Warp runs into timeout because of the HTTP request never reaches the LittleProxy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1958) Delete temporary instance root for Embedded Tomcat on exit

by Krassimir Valev (JIRA)

Krassimir Valev created ARQ-1958: ------------------------------------ Summary: Delete temporary instance root for Embedded Tomcat on exit Key: ARQ-1958 URL: https://issues.jboss.org/browse/ARQ-1958 Project: Arquillian Issue Type: Bug Components: Tomcat Containers Reporter: Krassimir Valev The embedded tomcat container (tested with version 7) does not cleanup temporary files after test execution - the temp folder is full of tomcat-embedded-***.tmp files. Similar issue was already reported for Glassfish - ARQ-923 that has already been resolved, but I guess nobody fixed the other containers. Looking at the source code of Glassfish, Tomcat and JBoss only the Glassfish one does setup deletion of the temp file within the setup() method: * https://github.com/arquillian/arquillian-container-glassfish/blob/master/... * https://github.com/arquillian/arquillian-container-tomcat/blob/master/tom... * https://github.com/arquillian/arquillian-container-jbossas/blob/master/jb... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1954) Support @Rule enrichement

by Matous Jobanek (JIRA)

[ https://issues.jboss.org/browse/ARQ-1954?page=com.atlassian.jira.plugin.s... ] Matous Jobanek commented on ARQ-1954: ------------------------------------- PR sent https://github.com/arquillian/arquillian-core/pull/85 > Support @Rule enrichement > ------------------------- > > Key: ARQ-1954 > URL: https://issues.jboss.org/browse/ARQ-1954 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.1.8.Final > Reporter: Karel Piwko > > Arquillian should by default enrich JUnit @Rule statements. > Similarly to https://github.com/aerogear/aerogear-testing-tools/blob/master/arquillian... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARQ-328) EJB-API dependencies in Weld EE container should be optional (causes failures on boot)

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/ARQ-328?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on ARQ-328: ------------------------------------- https://github.com/arquillian/arquillian-container-weld/pull/19 > EJB-API dependencies in Weld EE container should be optional (causes failures on boot) > -------------------------------------------------------------------------------------- > > Key: ARQ-328 > URL: https://issues.jboss.org/browse/ARQ-328 > Project: Arquillian > Issue Type: Feature Request > Components: Weld Containers > Affects Versions: 1.0.0.Alpha4 > Reporter: Lincoln Baxter III > > EJB APIs should be optional. If users do not supply the API jars, then EJB services should not attempt to load. This would enable easier configuration for those users who do not need EJB services, who only want Weld in EE-like container. > Currently the ejb-api maven dependency is required. > java.lang.NoClassDefFoundError: javax/ejb/Stateless > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.Ejbs.findEjbs(Ejbs.java:38) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.Ejbs.createEjbDescriptors(Ejbs.java:25) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:81) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.<init>(TestContainer.java:215) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:76) > at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:62) > at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:50) > at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63) > at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115) > at org.jboss.arquillian.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:96) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:162) > at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:186) > at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:297) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:182) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:127) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:24) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.junit.runner.JUnitCore.run(JUnitCore.java:157) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:64) > Caused by: java.lang.ClassNotFoundException: javax.ejb.Stateless > 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:307) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > ... 28 more -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARQ-328) EJB-API dependencies in Weld EE container should be optional (causes failures on boot)

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/ARQ-328?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on ARQ-328: ------------------------------------- This also causes problems with DeltaSpike > EJB-API dependencies in Weld EE container should be optional (causes failures on boot) > -------------------------------------------------------------------------------------- > > Key: ARQ-328 > URL: https://issues.jboss.org/browse/ARQ-328 > Project: Arquillian > Issue Type: Feature Request > Components: Weld Containers > Affects Versions: 1.0.0.Alpha4 > Reporter: Lincoln Baxter III > > EJB APIs should be optional. If users do not supply the API jars, then EJB services should not attempt to load. This would enable easier configuration for those users who do not need EJB services, who only want Weld in EE-like container. > Currently the ejb-api maven dependency is required. > java.lang.NoClassDefFoundError: javax/ejb/Stateless > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.Ejbs.findEjbs(Ejbs.java:38) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.Ejbs.createEjbDescriptors(Ejbs.java:25) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:81) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.<init>(TestContainer.java:215) > at org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:76) > at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:62) > at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:50) > at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63) > at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115) > at org.jboss.arquillian.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:96) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:162) > at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:186) > at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:297) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:182) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:127) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:24) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.junit.runner.JUnitCore.run(JUnitCore.java:157) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:64) > Caused by: java.lang.ClassNotFoundException: javax.ejb.Stateless > 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:307) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > ... 28 more -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1957) Internal TestResult in After is not correct when Test is failing in standalone mode

by Aslak Knutsen (JIRA)

Aslak Knutsen created ARQ-1957: ---------------------------------- Summary: Internal TestResult in After is not correct when Test is failing in standalone mode Key: ARQ-1957 URL: https://issues.jboss.org/browse/ARQ-1957 Project: Arquillian Issue Type: Bug Components: Base Implementation Affects Versions: 1.1.8.Final Reporter: Aslak Knutsen Assignee: Aslak Knutsen -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues June 2015