January 2014 - arquillian-issues - Jboss List Archives

[JBoss JIRA] (ARQ-553) NullPointerException in arquillianBeforeClass when running with testng in parallel

by Iwan Zarembo (JIRA)

[ https://issues.jboss.org/browse/ARQ-553?page=com.atlassian.jira.plugin.sy... ] Iwan Zarembo commented on ARQ-553: ---------------------------------- Hi, will this issue be resolved? It is already a few years old and nothing happened. The Issue in https://issues.jboss.org/browse/ARQ-127 contains also a test project to reproduce the issue. > NullPointerException in arquillianBeforeClass when running with testng in parallel > ---------------------------------------------------------------------------------- > > Key: ARQ-553 > URL: https://issues.jboss.org/browse/ARQ-553 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Base Implementation > Affects Versions: 1.0.0.CR1, 1.0.0.CR2 > Reporter: Tom Hintz > Priority: Critical > > Running with testng in parallel causes a NPE in org.jboss.arquillian.testng.Arquillian.arquillianBeforeClass(Arquillian.java:76), even with one thread. > testng runs arquillianBeforeSuite on main, but arquillianBeforeClass on pool-2-thread-1 -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1619) Tomcat managed container ignores allowConnectingToRunningServer

by Thomas Diesler (JIRA)

Thomas Diesler created ARQ-1619: ----------------------------------- Summary: Tomcat managed container ignores allowConnectingToRunningServer Key: ARQ-1619 URL: https://issues.jboss.org/browse/ARQ-1619 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Tomcat Containers Affects Versions: tomcat_1.0.0.CR5 Reporter: Thomas Diesler The flag is not checked {code} if(manager.isRunning()) { throw new LifecycleException( "The server is already running! " + "Managed containers does not support connecting to running server instances due to the " + "possible harmful effect of connecting to the wrong server. Please stop server before running or " + "change to another type of container.\n" + "To disable this check and allow Arquillian to connect to a running server, " + "set allowConnectingToRunningServer to true in the container configuration" ); } {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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1618) Transaction extension configuration is not loaded early enough when working with ArquillianSuiteExtension

by Pëtr Andreev (JIRA)

[ https://issues.jboss.org/browse/ARQ-1618?page=com.atlassian.jira.plugin.s... ] Pëtr Andreev commented on ARQ-1618: ----------------------------------- @Aslak: are there (m)any other issues preventing the Brute Force Extension to be incorporated into the ARQ master? I find that this extension is great enhancement saving lot of development time. > Transaction extension configuration is not loaded early enough when working with ArquillianSuiteExtension > --------------------------------------------------------------------------------------------------------- > > Key: ARQ-1618 > URL: https://issues.jboss.org/browse/ARQ-1618 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Transaction > Affects Versions: transaction_1.0.0.Final > Environment: Win7,CentOS > Jboss7, Wildfly8 > Reporter: Pëtr Andreev > Priority: Minor > > The TransactionConfigurationProducer loads an extension configuration on demand using the BeforeSuite event. This behaviour appears to be insufficient when Aslak`s Brute Force Arquillian Suite Extension is in play, since the Suite Extension interferes the test case bootstrap process and enforces early usage of ARQ components. > As a suggestion for TX-ext to support such a constellation the configuration loading of transaction extension can be moved right into the phase where ConfigurationRegistrar loads configurations and notifies observers about available ArquillianDescriptors. -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1618) Transaction extension configuration is not loaded early enough when working with ArquillianSuiteExtension

by Pëtr Andreev (JIRA)

[ https://issues.jboss.org/browse/ARQ-1618?page=com.atlassian.jira.plugin.s... ] Pëtr Andreev updated ARQ-1618: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-extension-transaction/pull/8 > Transaction extension configuration is not loaded early enough when working with ArquillianSuiteExtension > --------------------------------------------------------------------------------------------------------- > > Key: ARQ-1618 > URL: https://issues.jboss.org/browse/ARQ-1618 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Transaction > Affects Versions: transaction_1.0.0.Final > Environment: Win7,CentOS > Jboss7, Wildfly8 > Reporter: Pëtr Andreev > Priority: Minor > > The TransactionConfigurationProducer loads an extension configuration on demand using the BeforeSuite event. This behaviour appears to be insufficient when Aslak`s Brute Force Arquillian Suite Extension is in play, since the Suite Extension interferes the test case bootstrap process and enforces early usage of ARQ components. > As a suggestion for TX-ext to support such a constellation the configuration loading of transaction extension can be moved right into the phase where ConfigurationRegistrar loads configurations and notifies observers about available ArquillianDescriptors. -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1618) Transaction extension configuration is not loaded early enough when working with ArquillianSuiteExtension

by Pëtr Andreev (JIRA)

[ https://issues.jboss.org/browse/ARQ-1618?page=com.atlassian.jira.plugin.s... ] Pëtr Andreev updated ARQ-1618: ------------------------------ Summary: Transaction extension configuration is not loaded early enough when working with ArquillianSuiteExtension (was: Transaction extension configuration is not loaded early enough if working with ArquillianSuiteExtension) > Transaction extension configuration is not loaded early enough when working with ArquillianSuiteExtension > --------------------------------------------------------------------------------------------------------- > > Key: ARQ-1618 > URL: https://issues.jboss.org/browse/ARQ-1618 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Transaction > Affects Versions: transaction_1.0.0.Final > Environment: Win7,CentOS > Jboss7, Wildfly8 > Reporter: Pëtr Andreev > Priority: Minor > > The TransactionConfigurationProducer loads an extension configuration on demand using the BeforeSuite event. This behaviour appears to be insufficient when Aslak`s Brute Force Arquillian Suite Extension is in play, since the Suite Extension interferes the test case bootstrap process and enforces early usage of ARQ components. > As a suggestion for TX-ext to support such a constellation the configuration loading of transaction extension can be moved right into the phase where ConfigurationRegistrar loads configurations and notifies observers about available ArquillianDescriptors. -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1618) Transaction extension configuration is not loaded early enough if working with ArquillianSuiteExtension

by Pëtr Andreev (JIRA)

Pëtr Andreev created ARQ-1618: --------------------------------- Summary: Transaction extension configuration is not loaded early enough if working with ArquillianSuiteExtension Key: ARQ-1618 URL: https://issues.jboss.org/browse/ARQ-1618 Project: Arquillian Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Extension - Transaction Affects Versions: transaction_1.0.0.Final Environment: Win7,CentOS Jboss7, Wildfly8 Reporter: Pëtr Andreev Priority: Minor The TransactionConfigurationProducer loads an extension configuration on demand using the BeforeSuite event. This behaviour appears to be insufficient when Aslak`s Brute Force Arquillian Suite Extension is in play, since the Suite Extension interferes the test case bootstrap process and enforces early usage of ARQ components. As a suggestion for TX-ext to support such a constellation the configuration loading of transaction extension can be moved right into the phase where ConfigurationRegistrar loads configurations and notifies observers about available ArquillianDescriptors. -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQ-540) Support @ArquillianResource URL for in-container test cases

by Tom Eicher (JIRA)

[ https://issues.jboss.org/browse/ARQ-540?page=com.atlassian.jira.plugin.sy... ] Tom Eicher commented on ARQ-540: -------------------------------- There are valid use cases for "mixed tests" (in-container http tests), e.g. setup test using EJBs and Persistence Context, then send http request to the server, then user EJBs and Persistence Context again to verify the effects of the http call's operation. Thus, we need a way to know the URL in testable=true / non-RunAsClient tests. Injection like suggested in this issue would be the most straightforward solution from the user perspective. If that's not possible, or too much effort, please consider at least adding the URL to System.getProperties() or similar, so we can get the URL in any legal way. (currently there is none that I know of ... https://community.jboss.org/thread/235866 ) > Support @ArquillianResource URL for in-container test cases > ----------------------------------------------------------- > > Key: ARQ-540 > URL: https://issues.jboss.org/browse/ARQ-540 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 1.0.0.CR2 > Reporter: Ian Brandt > Fix For: 2.0.0.Beta1 > > > From [IRC|http://echelog.matzon.dk/logs/browse/jbosstesting/1312408800]: > {quote} > [2:13pm] ianbrandt: aslak, Should @ArquillianResource injection work for in-container test cases? It works fine when I try it for an as-client test, but when I do the same in-container the org.jboss.arquillian.container.test.impl.enricher.resource.URLResourceProvider.protocolMetadata.get() is null, so no context URL. I verified the container is returning a non-null ProtocolMetaData from deploy(...). > [2:15pm] aslak: ianbrandt, no it currently doesn't work > [2:16pm] aslak: ianbrandt, it probably should, but i'm not sure we have the info incontianer without doing a callback to the client.. > [2:16pm] aslak: ianbrandt, but then we don't know which deployment we are when incontianer, so we have a little problem there.. > [2:17pm] ianbrandt: aslak, Ah, okay. > [2:17pm] aslak: no wait we do > [2:18pm] aslak: the Protocol is executed within a DeploymentScope/ContainerScope, so when it gets the callback, it has the correct context.. > [2:18pm] aslak: we tho need OperatesOnDeployment support for that tho, cuz you possible want to inject URLs not to your self, but to another deployment on possible another contianer that you should invoke from incontainer > [2:19pm] aslak: so from incontianer on dep 1, we can do @ArqRes @OperatesOnDep("dep2") URL url; > [2:23pm] ianbrandt: aslak, Makes sense. It's a little more than I could take on at the moment. I was just augmenting the Tomcat tests to show @ArqRes usage. I'll skip it for shouldBeAbleToInvokeServletInDeployedWebApp, and JIRA+Wiki the limitation. > {quote} -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1489) response payload was never registered when used with OCPsoft Rewrite

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1489?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated ARQ-1489: ---------------------------- Description: I use OCPsoft Rewrite (http://ocpsoft.org/rewrite/) to add fancy URL aliases to my JSF webapp. Warp tests work as long as I use the original unaliased URLs. Warp tests using the aliased URLs fail with {quote} ClientWarpExecutionException: deenriching response failed: The response payload with serialId [...] was never registered {quote} I created a demonstration project, see README.md for details: https://github.com/albers/arquillian-showcase/tree/rewrite was: I use OCPsoft Rewrite (http://ocpsoft.org/rewrite/) to add fancy URL aliases to my JSF webapp. Warp tests work as long as I use the original unaliased URLs. Warp tests using the aliased URLs fail with ClientWarpExecutionException: deenriching response failed: The response payload with serialId [...] was never registered I created a demonstration project, see README.md for details: https://github.com/albers/arquillian-showcase/tree/rewrite > response payload was never registered when used with OCPsoft Rewrite > -------------------------------------------------------------------- > > Key: ARQ-1489 > URL: https://issues.jboss.org/browse/ARQ-1489 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: 1.0.0.Alpha4 > Environment: Arquillian Warp 1.0.0.Alpha4 with Rewrite 2.0.7.Final in a JBoss AS 7.1.1.Final > Reporter: Harald Albers > Fix For: warp_1.0.0.Alpha6 > > > I use OCPsoft Rewrite (http://ocpsoft.org/rewrite/) to add fancy URL aliases to my JSF webapp. > Warp tests work as long as I use the original unaliased URLs. > Warp tests using the aliased URLs fail with > {quote} > ClientWarpExecutionException: deenriching response failed: The response payload with serialId [...] was never registered > {quote} > I created a demonstration project, see README.md for details: > https://github.com/albers/arquillian-showcase/tree/rewrite -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1562) Warp: doesn't provide a built-in support for matching GET/POST requests by their parameters

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1562?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated ARQ-1562: ---------------------------- Forum Reference: https://community.jboss.org/thread/234234 > Warp: doesn't provide a built-in support for matching GET/POST requests by their parameters > ------------------------------------------------------------------------------------------- > > Key: ARQ-1562 > URL: https://issues.jboss.org/browse/ARQ-1562 > Project: Arquillian > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: warp_1.0.0.Alpha5 > Reporter: Lukáš Fryč > Priority: Critical > Fix For: warp_1.0.0.Alpha6 > > -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1561) Warp proxy tries to rewrite binary files

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQ-1561?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč resolved ARQ-1561. ----------------------------- Assignee: Lukáš Fryč Resolution: Done > Warp proxy tries to rewrite binary files > ---------------------------------------- > > Key: ARQ-1561 > URL: https://issues.jboss.org/browse/ARQ-1561 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Warp > Affects Versions: 1.0.0.Alpha5 > Reporter: Jan Dosoudil > Assignee: Lukáš Fryč > Priority: Critical > Fix For: warp_1.0.0.Alpha6 > > Attachments: empty.png, empty2.png > > > It's related to ARQ-1552 - rewrite calls new String(byte[]) on response byte[] which may fail on binary files. -- 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

10 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues January 2014