September 2013 - arquillian-issues

[JBoss JIRA] (ARQGRA-308) Should throw exception if page fragment not instantiable

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-308?page=com.atlassian.jira.plugin... ] Lukáš Fryč commented on ARQGRA-308: ----------------------------------- The exception should be thrown in this case, since the fix is pretty straight-forward. It's a user's mistake to define non-instantiable class and test shouldn't even start when such an issue occurs -> so, throw exception. > Should throw exception if page fragment not instantiable > -------------------------------------------------------- > > Key: ARQGRA-308 > URL: https://issues.jboss.org/browse/ARQGRA-308 > Project: Arquillian Graphene > Issue Type: Bug > Affects Versions: 2.0.0.Alpha4 > Reporter: Bernard Labno > Assignee: Juraj Húska > Fix For: 2.0.0.Beta1 > > > If page fragment is inner final class then it's not injected into field annotated with @FindBy and no exception is thrown. > Graphene should throw exception that desired class cannot be instantiated. > Right now user spends lots of time debugging and wondering if the selector is wrong. It's hard to find out that it's the "final" word to be blamed here: > public static final class InvitedSupplier -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-357) Support for setting custom defaultElementLocatingStrategy

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-357?page=com.atlassian.jira.plugin... ] Lukáš Fryč updated ARQGRA-357: ------------------------------ Fix Version/s: 2.0.0.Beta1 > Support for setting custom defaultElementLocatingStrategy > --------------------------------------------------------- > > Key: ARQGRA-357 > URL: https://issues.jboss.org/browse/ARQGRA-357 > Project: Arquillian Graphene > Issue Type: Enhancement > Components: core > Affects Versions: 2.0.0.Alpha5 > Reporter: Juraj Húska > Priority: Minor > Fix For: 2.0.0.Beta1 > > > Since we support extending the locating strategy, e.g. {{FindByJQuery}}, we should also support setting of such custom locating strategy as: > {{defaultLocatingStrategy}} for all FindBys. > The non ability to do so is hidden [here|https://github.com/arquillian/arquillian-graphene/blob/master/impl/s...]. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1474) When security auths are enabled, always receive a 401 unauthorized

by John Ament (JIRA)

[ https://issues.jboss.org/browse/ARQ-1474?page=com.atlassian.jira.plugin.s... ] John Ament commented on ARQ-1474: --------------------------------- So, after troubleshooting this a while longer (and nearly rage-quitting programming), I found that Arquillian would only work with the "other" domain, regardless of the specified realm-name in web.xml. I was able to change the other domain to use my internal scheme. > When security auths are enabled, always receive a 401 unauthorized > ------------------------------------------------------------------ > > Key: ARQ-1474 > URL: https://issues.jboss.org/browse/ARQ-1474 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: John Ament > > Arquillian won't accept authentication headers, no matter how hard I try. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1474) When security auths are enabled, always receive a 401 unauthorized

by John Ament (JIRA)

[ https://issues.jboss.org/browse/ARQ-1474?page=com.atlassian.jira.plugin.s... ] John Ament updated ARQ-1474: ---------------------------- Steps to Reproduce: Created a simple security auth in my web.xml {noformat} <security-constraint> <web-resource-collection> <web-resource-name>REST API</web-resource-name> <url-pattern>/rest/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>webservice</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>wsidp</realm-name> </login-config> <security-role> <role-name>webservice</role-name> </security-role> {noformat} Develop a simple REST API that uses this: {noformat} @Path("/echo") public interface SimpleAPI { @GET @Produces("text/plain") public String echo(@HeaderParam("Authorization") final String auth); } {noformat} where the REST API is bound to /rest Add an Arquillian test: {noformat} private <T> T getClientProxy(Class<T> className) { RegisterBuiltin.register(ResteasyProviderFactory.getInstance()); final String contextUrl = "http://localhost:8082/webservices/rest"; //return JAXRSClientFactory.create(contextUrl,className); return (T) ProxyFactory.create(className, contextUrl); } @Deployment(name="ee-webservices.war") public static org.jboss.shrinkwrap.api.spec.WebArchive createDeployment() { return DeploymentUtils.createWebserviceForTest().addClass(WebServiceInfoAPI.class); } @Test @OperateOnDeployment("ee-webservices.war") public void createWebServiceUser() throws InterruptedException { String username = "bob"; String password = "abc123"; byte[] data = String.format("%s:%s",username,password).getBytes(); BASE64Encoder encoder = new BASE64Encoder(); String auth = "Basic "+ encoder.encode(data); System.out.println("basic auth "+auth); //Thread.sleep(4*60*1000); SimpleAPI api = this.getClientProxy(SimpleAPI.class); String result = api.echo(auth); Assert.assertEquals("Hello", result); } {noformat} And receive back a 401 unauthorized. When I comment out the thread call, and invoke the REST API manually, I also see that the server is prompting for authentication but never accepting it. I can see in the logs that my login module is never called. I can confirm that when this same WAR file is deployed to the server directly, authentication works. I did see that the Servlet protocol does not support authentication. This shouldn't be an issue here, since my auth is only against /webservices/rest, and not against /webservices/ArquillianServletRunner. This is using Arquillian 1.0.4 Final on JBoss EAP 6.1, with upgraded picketlink 2.1.7. was: Created a simple security auth in my web.xml <security-constraint> <web-resource-collection> <web-resource-name>REST API</web-resource-name> <url-pattern>/rest/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>webservice</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>wsidp</realm-name> </login-config> <security-role> <role-name>webservice</role-name> </security-role> Develop a simple REST API that uses this: @Path("/echo") public interface SimpleAPI { @GET @Produces("text/plain") public String echo(@HeaderParam("Authorization") final String auth); } where the REST API is bound to /rest Add an Arquillian test: private <T> T getClientProxy(Class<T> className) { RegisterBuiltin.register(ResteasyProviderFactory.getInstance()); final String contextUrl = "http://localhost:8082/webservices/rest"; //return JAXRSClientFactory.create(contextUrl,className); return (T) ProxyFactory.create(className, contextUrl); } @Deployment(name="ee-webservices.war") public static org.jboss.shrinkwrap.api.spec.WebArchive createDeployment() { return DeploymentUtils.createWebserviceForTest().addClass(WebServiceInfoAPI.class); } @Test @OperateOnDeployment("ee-webservices.war") public void createWebServiceUser() throws InterruptedException { String username = "bob"; String password = "abc123"; byte[] data = String.format("%s:%s",username,password).getBytes(); BASE64Encoder encoder = new BASE64Encoder(); String auth = "Basic "+ encoder.encode(data); System.out.println("basic auth "+auth); //Thread.sleep(4*60*1000); SimpleAPI api = this.getClientProxy(SimpleAPI.class); String result = api.echo(auth); Assert.assertEquals("Hello", result); } And receive back a 401 unauthorized. When I comment out the thread call, and invoke the REST API manually, I also see that the server is prompting for authentication but never accepting it. I can see in the logs that my login module is never called. I can confirm that when this same WAR file is deployed to the server directly, authentication works. I did see that the Servlet protocol does not support authentication. This shouldn't be an issue here, since my auth is only against /webservices/rest, and not against /webservices/ArquillianServletRunner. This is using Arquillian 1.0.4 Final on JBoss EAP 6.1, with upgraded picketlink 2.1.7. > When security auths are enabled, always receive a 401 unauthorized > ------------------------------------------------------------------ > > Key: ARQ-1474 > URL: https://issues.jboss.org/browse/ARQ-1474 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: John Ament > > Arquillian won't accept authentication headers, no matter how hard I try. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1474) When security auths are enabled, always receive a 401 unauthorized

by John Ament (JIRA)

John Ament created ARQ-1474: ------------------------------- Summary: When security auths are enabled, always receive a 401 unauthorized Key: ARQ-1474 URL: https://issues.jboss.org/browse/ARQ-1474 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Reporter: John Ament Arquillian won't accept authentication headers, no matter how hard I try. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1077) Persistence Plugin does not work with Drone/Graphene

by alain-michel chomnoue nghemning (JIRA)

[ https://issues.jboss.org/browse/ARQ-1077?page=com.atlassian.jira.plugin.s... ] alain-michel chomnoue nghemning commented on ARQ-1077: ------------------------------------------------------ you can avoid your first test method cleanning up test data by adding @Cleanup(phase=NONE) after @UsingDataSet > Persistence Plugin does not work with Drone/Graphene > ---------------------------------------------------- > > Key: ARQ-1077 > URL: https://issues.jboss.org/browse/ARQ-1077 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Drone, Extension - Persistence > Environment: JBoss AS 7 Container > Reporter: Bryan Saunders > Labels: drone, persistence > > Persistence Extension does not execute when being used with the Drone/Graphene extensions. When you run the tests in Client Mode the @UsingDataSet annotations do not trigger and populate the database. @ApplyScriptBefore also does not work. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1077) Persistence Plugin does not work with Drone/Graphene

by alain-michel chomnoue nghemning (JIRA)

[ https://issues.jboss.org/browse/ARQ-1077?page=com.atlassian.jira.plugin.s... ] alain-michel chomnoue nghemning edited comment on ARQ-1077 at 9/7/13 6:22 AM: ------------------------------------------------------------------------------ you can avoid your first test method cleanning up test data by adding @Cleanup(phase=NONE) after @UsingDataSet or on the first test method was (Author: chomnoue): you can avoid your first test method cleanning up test data by adding @Cleanup(phase=NONE) after @UsingDataSet > Persistence Plugin does not work with Drone/Graphene > ---------------------------------------------------- > > Key: ARQ-1077 > URL: https://issues.jboss.org/browse/ARQ-1077 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Extension - Drone, Extension - Persistence > Environment: JBoss AS 7 Container > Reporter: Bryan Saunders > Labels: drone, persistence > > Persistence Extension does not execute when being used with the Drone/Graphene extensions. When you run the tests in Client Mode the @UsingDataSet annotations do not trigger and populate the database. @ApplyScriptBefore also does not work. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1473) JUnit @Before and @After cause nested transaction

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1473?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak reassigned ARQ-1473: ----------------------------------- Assignee: Bartosz Majsak > JUnit @Before and @After cause nested transaction > ------------------------------------------------- > > Key: ARQ-1473 > URL: https://issues.jboss.org/browse/ARQ-1473 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Transaction > Affects Versions: 1.0.0.Alpha3 > Reporter: jieryn jieryn > Assignee: Bartosz Majsak > Priority: Minor > > @Before and @After methods on embedded containers cause a nested transaction, which are often not supported, leading to an exception. > I confirmed this bug with aslak on IRC. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1473) JUnit @Before and @After cause nested transaction

by jieryn jieryn (JIRA)

[ https://issues.jboss.org/browse/ARQ-1473?page=com.atlassian.jira.plugin.s... ] jieryn jieryn commented on ARQ-1473: ------------------------------------ See https://github.com/jieryn/javaee-example/tree/ARQ-1473 for a simple example project exhibiting the problem. > JUnit @Before and @After cause nested transaction > ------------------------------------------------- > > Key: ARQ-1473 > URL: https://issues.jboss.org/browse/ARQ-1473 > Project: Arquillian > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Extension - Transaction > Affects Versions: 1.0.0.Alpha3 > Reporter: jieryn jieryn > Priority: Minor > > @Before and @After methods on embedded containers cause a nested transaction, which are often not supported, leading to an exception. > I confirmed this bug with aslak on IRC. -- 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

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1473) JUnit @Before and @After cause nested transaction

by jieryn jieryn (JIRA)

jieryn jieryn created ARQ-1473: ---------------------------------- Summary: JUnit @Before and @After cause nested transaction Key: ARQ-1473 URL: https://issues.jboss.org/browse/ARQ-1473 Project: Arquillian Issue Type: Bug Security Level: Public (Everyone can see) Components: Extension - Transaction Affects Versions: 1.0.0.Alpha3 Reporter: jieryn jieryn Priority: Minor @Before and @After methods on embedded containers cause a nested transaction, which are often not supported, leading to an exception. I confirmed this bug with aslak on IRC. -- 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

12 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues September 2013