[JBoss JIRA] (ARQ-2109) EJBInjectionEnricher makes too strong assumptions about JNDI names in the "anonymous" case
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2109?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-2109:
--------------------------------
Affects Version/s: 1.1.13.Final
> EJBInjectionEnricher makes too strong assumptions about JNDI names in the "anonymous" case
> ------------------------------------------------------------------------------------------
>
> Key: ARQ-2109
> URL: https://issues.jboss.org/browse/ARQ-2109
> Project: Arquillian
> Issue Type: Bug
> Components: Runtime Enricher SPI
> Affects Versions: 1.1.13.Final
> Reporter: Ladislav Thon
>
> The {{EJBInjectionEnricher}} supports injecting the test instance fields annotated with {{javax.ejb.EJB}}. However, looking at the {{EJBInjectionEnricher.getJndiNamesForAnonymousEJB}} method, it makes too strong assumptions about the JNDI name. Specifically, it assumes the {{test.ear}} and {{test}} names. That doesn't necessarily have to be correct (e.g. WildFly Swarm Arquillian adapter doesn't use these names). There's an easy way to improve this for some situations: also consider the {{java:module}} portable namespace. It can't fix all situations, but it does fix some of them. (For Swarm, it's completely enough, since Swarm doesn't support EARs.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (ARQ-2109) EJBInjectionEnricher makes too strong assumptions about JNDI names in the "anonymous" case
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2109?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-2109:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> EJBInjectionEnricher makes too strong assumptions about JNDI names in the "anonymous" case
> ------------------------------------------------------------------------------------------
>
> Key: ARQ-2109
> URL: https://issues.jboss.org/browse/ARQ-2109
> Project: Arquillian
> Issue Type: Bug
> Components: Runtime Enricher SPI
> Affects Versions: 1.1.13.Final
> Reporter: Ladislav Thon
>
> The {{EJBInjectionEnricher}} supports injecting the test instance fields annotated with {{javax.ejb.EJB}}. However, looking at the {{EJBInjectionEnricher.getJndiNamesForAnonymousEJB}} method, it makes too strong assumptions about the JNDI name. Specifically, it assumes the {{test.ear}} and {{test}} names. That doesn't necessarily have to be correct (e.g. WildFly Swarm Arquillian adapter doesn't use these names). There's an easy way to improve this for some situations: also consider the {{java:module}} portable namespace. It can't fix all situations, but it does fix some of them. (For Swarm, it's completely enough, since Swarm doesn't support EARs.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (ARQ-2107) ResourceInjectionEnricher doesn't consult the @Resource(lookup = "...") value
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2107?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-2107:
--------------------------------
Affects Version/s: 1.1.13.Final
> ResourceInjectionEnricher doesn't consult the @Resource(lookup = "...") value
> -----------------------------------------------------------------------------
>
> Key: ARQ-2107
> URL: https://issues.jboss.org/browse/ARQ-2107
> Project: Arquillian
> Issue Type: Bug
> Components: Runtime Enricher SPI
> Affects Versions: 1.1.13.Final
> Reporter: Ladislav Thon
>
> The {{ResourceInjectionEnricher}} supports injecting the test instance fields annotated with {{javax.annotation.Resource}}. However, looking at the {{ResourceInjectionEnricher.getResourceName}} method, it only consults the annotation's {{name}} and {{mappedName}} attributes, falling back to some default afterward. The annotation's {{lookup}} attribute isn't considered at all. This might be because the {{lookup}} attribute was only added in Java EE 6 / Java SE 7, and Arquillian still supports Java 6, but that can be solved with a little bit of reflection.
> I don't know if this omission was intentional or not, but it could have easily gone unnoticed for a long while, because if CDI is present, the {{CDIInjectionEnricher}} will inject such field. However, CDI doesn't necessarily have to be present -- for example with WildFly Swarm.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (ARQ-2107) ResourceInjectionEnricher doesn't consult the @Resource(lookup = "...") value
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2107?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-2107:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/arquillian/arquillian-core/pull/127
> ResourceInjectionEnricher doesn't consult the @Resource(lookup = "...") value
> -----------------------------------------------------------------------------
>
> Key: ARQ-2107
> URL: https://issues.jboss.org/browse/ARQ-2107
> Project: Arquillian
> Issue Type: Bug
> Components: Runtime Enricher SPI
> Reporter: Ladislav Thon
>
> The {{ResourceInjectionEnricher}} supports injecting the test instance fields annotated with {{javax.annotation.Resource}}. However, looking at the {{ResourceInjectionEnricher.getResourceName}} method, it only consults the annotation's {{name}} and {{mappedName}} attributes, falling back to some default afterward. The annotation's {{lookup}} attribute isn't considered at all. This might be because the {{lookup}} attribute was only added in Java EE 6 / Java SE 7, and Arquillian still supports Java 6, but that can be solved with a little bit of reflection.
> I don't know if this omission was intentional or not, but it could have easily gone unnoticed for a long while, because if CDI is present, the {{CDIInjectionEnricher}} will inject such field. However, CDI doesn't necessarily have to be present -- for example with WildFly Swarm.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months
[JBoss JIRA] (ARQGRA-501) Error when checking for the invisibility of elements
by Matous Jobanek (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-501?page=com.atlassian.jira.plugin... ]
Matous Jobanek closed ARQGRA-501.
---------------------------------
Resolution: Done
Pushed upstream in https://github.com/arquillian/arquillian-graphene/commit/cd1e4b5028c4861f...
> Error when checking for the invisibility of elements
> ----------------------------------------------------
>
> Key: ARQGRA-501
> URL: https://issues.jboss.org/browse/ARQGRA-501
> Project: Arquillian Graphene
> Issue Type: Bug
> Affects Versions: 2.2.0
> Reporter: Krassimir Valev
> Assignee: Matous Jobanek
> Fix For: 2.3.0
>
>
> I get the following error message, when waiting for an element to disappear:
> {code:java}
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:653)
> at java.util.ArrayList.get(ArrayList.java:429)
> at org.jboss.arquillian.graphene.enricher.WebElementUtils$3.getTarget(WebElementUtils.java:104)
> at org.jboss.arquillian.graphene.proxy.GrapheneProxyHandler.getTarget(GrapheneProxyHandler.java:149)
> at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler$1.getTarget(GrapheneContextualHandler.java:189)
> at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler$1.invoke(GrapheneContextualHandler.java:162)
> at org.jboss.arquillian.graphene.enricher.SearchContextInterceptor.intercept(SearchContextInterceptor.java:50)
> at org.jboss.arquillian.graphene.proxy.InvocationContextImpl.invoke(InvocationContextImpl.java:87)
> at org.jboss.arquillian.graphene.enricher.StaleElementInterceptor$1.apply(StaleElementInterceptor.java:47)
> at org.jboss.arquillian.graphene.enricher.StaleElementInterceptor$1.apply(StaleElementInterceptor.java:43)
> at org.openqa.selenium.support.ui.FluentWait.until(FluentWait.java:209)
> at org.jboss.arquillian.graphene.wait.WebDriverWaitImpl.until(WebDriverWaitImpl.java:96)
> at org.jboss.arquillian.graphene.enricher.StaleElementInterceptor.intercept(StaleElementInterceptor.java:43)
> at org.jboss.arquillian.graphene.proxy.InvocationContextImpl.invoke(InvocationContextImpl.java:87)
> at org.jboss.arquillian.graphene.intercept.InterceptorBuilder$2.intercept(InterceptorBuilder.java:139)
> at org.jboss.arquillian.graphene.proxy.InvocationContextImpl.invoke(InvocationContextImpl.java:87)
> at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler$2.call(GrapheneContextualHandler.java:212)
> at org.jboss.arquillian.graphene.context.BrowserActions.performAction(BrowserActions.java:62)
> at org.jboss.arquillian.graphene.proxy.GrapheneContextualHandler.invoke(GrapheneContextualHandler.java:208)
> at com.sun.proxy.$Proxy316.isDisplayed(Unknown Source)
> at org.openqa.selenium.support.ui.ExpectedConditions$20.apply(ExpectedConditions.java:585)
> at org.openqa.selenium.support.ui.ExpectedConditions$20.apply(ExpectedConditions.java:581)
> at org.openqa.selenium.support.ui.FluentWait.until(FluentWait.java:209)
> at org.jboss.arquillian.graphene.wait.WebDriverWaitImpl.until(WebDriverWaitImpl.java:96)
> {code}
> The wait condition looks like this:
> {code:java}
> return waitGui()
> .withTimeout(timeout, TimeUnit.SECONDS)
> .pollingEvery(100, TimeUnit.MILLISECONDS)
> .ignoring(NoSuchElementException.class, StaleElementReferenceException.class)
> .ignoring(InvocationTargetException.class)
> .until(ExpectedConditions.invisibilityOfElementLocated(locator));
> {code}
> The very same condition used to work with graphene-webdriver 2.0.3.Final and selenium-bom 2.50.1, but it fails now after upgrading to graphene-webdriver 2.2.0 and selenium-bom 3.3.1
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 5 months