November 2017 - arquillian-issues

[JBoss JIRA] (ARQ-2152) Add support for setting 'apiTypeVisibility' in Websphere Liberty Application Server Container

by Gordon Hutchison (JIRA)

[ https://issues.jboss.org/browse/ARQ-2152?page=com.atlassian.jira.plugin.s... ] Gordon Hutchison edited comment on ARQ-2152 at 11/16/17 9:27 AM: ----------------------------------------------------------------- An example arquillian.xml (tck/src/test/resources/arquillian.xml) that sets this element into server.xml is (look for apiTypeVisibility") {code:java} <?xml version="1.0" encoding="UTF-8" standalone="yes"?>  <arquillian xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://jboss.org/schema/arquillian" xsi:schemaLocation="http://jboss.org/schema/arquillian http://jboss.org/schema/arquillian/arquillian_1_0.xsd"> <defaultProtocol type="Servlet 3.0" /> <engine> <property name="deploymentExportPath">target/</property> </engine> <container qualifier="websphere" default="true"> <configuration> <property name="wlpHome">/work/liberty/src/libertyGit/open-liberty/dev/build.image/wlp</property> <property name="serverName">server1</property> <property name="httpPort">9080</property> <property name="allowConnectingToRunningServer">true</property> <property name="deployType">xml</property> <property name="apiTypeVisibility">spec, ibm-api, third-party</property> </configuration> </container> </arquillian> {code} was (Author: hutchig): An example arquillian.xml (tck/src/test/resources/arquillian.xml) that sets this elelement into server.xml is: {code:java} <?xml version="1.0" encoding="UTF-8" standalone="yes"?>  <arquillian xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://jboss.org/schema/arquillian" xsi:schemaLocation="http://jboss.org/schema/arquillian http://jboss.org/schema/arquillian/arquillian_1_0.xsd"> <defaultProtocol type="Servlet 3.0" /> <engine> <property name="deploymentExportPath">target/</property> </engine> <container qualifier="websphere" default="true"> <configuration> <property name="wlpHome">/work/liberty/src/libertyGit/open-liberty/dev/build.image/wlp</property> <property name="serverName">server1</property> <property name="httpPort">9080</property> <property name="allowConnectingToRunningServer">true</property> <property name="deployType">xml</property> <property name="apiTypeVisibility">spec, ibm-api, third-party</property> </configuration> </container> </arquillian> {code} > Add support for setting 'apiTypeVisibility' in Websphere Liberty Application Server Container > ---------------------------------------------------------------------------------------------- > > Key: ARQ-2152 > URL: https://issues.jboss.org/browse/ARQ-2152 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Affects Versions: was_1.0.0.next > Environment: Testing Microprofile TCKs on WebSphere Liberty > (Apologies for setting the priority.) > (Apologies if the version is incorrect for https://github.com/arquillian/arquillian-container-was/tree/master/wlp-ma... > Reporter: Gordon Hutchison > Assignee: Gerhard Poul > Priority: Minor > > (I have to thank my colleague Kevin Grigorenko for this patch which I integrated into > my local clone. The text below is pasted from text written by him: ) > "Added support for injecting a Tracer into the TCK: For the CDI injection to work, the TCK application's classloader must be configured with apiTypeVisibility="spec, ibm-api, third-party". The WAS Arquillian container's default deployType is dropins and I couldn't find a way to configure the classloader for that. The WAS Arquiallian container also supports deployType=xml which puts the WAR into apps and dynamically adds configuration to Liberty's server.xml with the <application /> element and some sub-elements. I forked that code to also add support for apiTypeVisibility and also submitted a pull request. Now, running with that fork and specifying <property name="deployType">xml</property> and <property name="apiTypeVisibility">spec, ibm-api, third-party</property> in mpOpentracingTckRunner/tck/src/test/resources/arquillian.xml allows the TCK to inject the Tracer." > This WLP feature is discussed here: > https://www.ibm.com/support/knowledgecenter/en/SSEQTP_8.5.5/com.ibm.websp... > I have Kevin's code patch that does this and am only raising this issue > in order to reference it in a pull request I am going to make > at > https://github.com/arquillian/arquillian-container-was/tree/master/wlp-ma... > I have checked with Kevin that he is happy for me to do this: > (On IBM Sametime) > gordon_hutchison(a)uk.ibm.com - Gordon Hutchison/UK/IBM: > 4:17:28 PM: Hi Kevin, is it OK with you if I create an issue and then a PR to integrate the 'apiTypeVisibility' change you did to the public upstream repo? > Kevin GRIGORENKO: > 4:17:54 PM: Yes, absolutely. Thanks very much! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ARQ-2152) Add support for setting 'apiTypeVisibility' in Websphere Liberty Application Server Container

by Gordon Hutchison (JIRA)

[ https://issues.jboss.org/browse/ARQ-2152?page=com.atlassian.jira.plugin.s... ] Gordon Hutchison commented on ARQ-2152: --------------------------------------- An example arquillian.xml (tck/src/test/resources/arquillian.xml) that sets this elelement into server.xml is: {code:java} <?xml version="1.0" encoding="UTF-8" standalone="yes"?>  <arquillian xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://jboss.org/schema/arquillian" xsi:schemaLocation="http://jboss.org/schema/arquillian http://jboss.org/schema/arquillian/arquillian_1_0.xsd"> <defaultProtocol type="Servlet 3.0" /> <engine> <property name="deploymentExportPath">target/</property> </engine> <container qualifier="websphere" default="true"> <configuration> <property name="wlpHome">/work/liberty/src/libertyGit/open-liberty/dev/build.image/wlp</property> <property name="serverName">server1</property> <property name="httpPort">9080</property> <property name="allowConnectingToRunningServer">true</property> <property name="deployType">xml</property> <property name="apiTypeVisibility">spec, ibm-api, third-party</property> </configuration> </container> </arquillian> {code} > Add support for setting 'apiTypeVisibility' in Websphere Liberty Application Server Container > ---------------------------------------------------------------------------------------------- > > Key: ARQ-2152 > URL: https://issues.jboss.org/browse/ARQ-2152 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Affects Versions: was_1.0.0.next > Environment: Testing Microprofile TCKs on WebSphere Liberty > (Apologies for setting the priority.) > (Apologies if the version is incorrect for https://github.com/arquillian/arquillian-container-was/tree/master/wlp-ma... > Reporter: Gordon Hutchison > Assignee: Gerhard Poul > Priority: Minor > > (I have to thank my colleague Kevin Grigorenko for this patch which I integrated into > my local clone. The text below is pasted from text written by him: ) > "Added support for injecting a Tracer into the TCK: For the CDI injection to work, the TCK application's classloader must be configured with apiTypeVisibility="spec, ibm-api, third-party". The WAS Arquillian container's default deployType is dropins and I couldn't find a way to configure the classloader for that. The WAS Arquiallian container also supports deployType=xml which puts the WAR into apps and dynamically adds configuration to Liberty's server.xml with the <application /> element and some sub-elements. I forked that code to also add support for apiTypeVisibility and also submitted a pull request. Now, running with that fork and specifying <property name="deployType">xml</property> and <property name="apiTypeVisibility">spec, ibm-api, third-party</property> in mpOpentracingTckRunner/tck/src/test/resources/arquillian.xml allows the TCK to inject the Tracer." > This WLP feature is discussed here: > https://www.ibm.com/support/knowledgecenter/en/SSEQTP_8.5.5/com.ibm.websp... > I have Kevin's code patch that does this and am only raising this issue > in order to reference it in a pull request I am going to make > at > https://github.com/arquillian/arquillian-container-was/tree/master/wlp-ma... > I have checked with Kevin that he is happy for me to do this: > (On IBM Sametime) > gordon_hutchison(a)uk.ibm.com - Gordon Hutchison/UK/IBM: > 4:17:28 PM: Hi Kevin, is it OK with you if I create an issue and then a PR to integrate the 'apiTypeVisibility' change you did to the public upstream repo? > Kevin GRIGORENKO: > 4:17:54 PM: Yes, absolutely. Thanks very much! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ARQ-2136) Add support to preserve original property value using placeholder

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-2136?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak updated ARQ-2136: -------------------------------- Fix Version/s: 1.1.14.Final > Add support to preserve original property value using placeholder > ----------------------------------------------------------------- > > Key: ARQ-2136 > URL: https://issues.jboss.org/browse/ARQ-2136 > Project: Arquillian > Issue Type: Enhancement > Components: Configuration > Affects Versions: 1.1.13.Final > Reporter: Bartosz Majsak > Assignee: Bartosz Majsak > Priority: Minor > Fix For: 1.1.14.Final > > > https://github.com/arquillian/arquillian-core/pull/122 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[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: -------------------------------- Fix Version/s: 1.1.14.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 > Fix For: 1.1.14.Final > > > 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.5.0#75005)

7 years, 1 month

1
0
0 / 0

[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: -------------------------------- Fix Version/s: 1.1.14.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 > Fix For: 1.1.14.Final > > > 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.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ARQ-2143) Deployments that expect exceptions are not testable.

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-2143?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak updated ARQ-2143: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Deployments that expect exceptions are not testable. > ---------------------------------------------------- > > Key: ARQ-2143 > URL: https://issues.jboss.org/browse/ARQ-2143 > Project: Arquillian > Issue Type: Bug > Reporter: John Ament > Fix For: 1.1.14.Final > > > Microprofile has some spec tests that rely on throwing exceptions on deployment. https://github.com/eclipse/microprofile-jwt-auth/blob/master/tck/src/test... is one such test (ignore that it doesn't extend Arquillian). > The problem is that its not the code in the package that generates the exception, but classes added via an ArchiveProcessor, e.g. a CDI extension, that will generate the exception. > I'm not sure the reasoning behind this behavior, but I don't see why {{ShouldThrowException}} implies that an archive is not testable. Can this behavior be changed? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ARQ-2117) Confusing warning message from observer

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-2117?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak updated ARQ-2117: -------------------------------- Fix Version/s: 1.1.14.Final > Confusing warning message from observer > --------------------------------------- > > Key: ARQ-2117 > URL: https://issues.jboss.org/browse/ARQ-2117 > Project: Arquillian > Issue Type: Enhancement > Components: Base Implementation > Reporter: Bartosz Majsak > Assignee: Dipak Pawar > Priority: Minor > Fix For: 1.1.14.Final > > > When observer has one of the arguments null following warning is displayed: > {{WARNING [org.jboss.arquillian.core.spi.ObserverMethod] (main) Argument 2 for ArquillianServiceDeployer.doServiceDeploy is null. It won't be invoked.}} > It's been introduced for debugging purposes and it's just confusing for the users. > We should only display it when {{arquillian.debug=true}} is enabled. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ARQ-2143) Deployments that expect exceptions are not testable.

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-2143?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak updated ARQ-2143: -------------------------------- Component/s: Base Implementation > Deployments that expect exceptions are not testable. > ---------------------------------------------------- > > Key: ARQ-2143 > URL: https://issues.jboss.org/browse/ARQ-2143 > Project: Arquillian > Issue Type: Bug > Components: Base Implementation > Reporter: John Ament > Fix For: 1.1.14.Final > > > Microprofile has some spec tests that rely on throwing exceptions on deployment. https://github.com/eclipse/microprofile-jwt-auth/blob/master/tck/src/test... is one such test (ignore that it doesn't extend Arquillian). > The problem is that its not the code in the package that generates the exception, but classes added via an ArchiveProcessor, e.g. a CDI extension, that will generate the exception. > I'm not sure the reasoning behind this behavior, but I don't see why {{ShouldThrowException}} implies that an archive is not testable. Can this behavior be changed? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ARQ-2143) Deployments that expect exceptions are not testable.

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-2143?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak updated ARQ-2143: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/135 > Deployments that expect exceptions are not testable. > ---------------------------------------------------- > > Key: ARQ-2143 > URL: https://issues.jboss.org/browse/ARQ-2143 > Project: Arquillian > Issue Type: Bug > Reporter: John Ament > Fix For: 1.1.14.Final > > > Microprofile has some spec tests that rely on throwing exceptions on deployment. https://github.com/eclipse/microprofile-jwt-auth/blob/master/tck/src/test... is one such test (ignore that it doesn't extend Arquillian). > The problem is that its not the code in the package that generates the exception, but classes added via an ArchiveProcessor, e.g. a CDI extension, that will generate the exception. > I'm not sure the reasoning behind this behavior, but I don't see why {{ShouldThrowException}} implies that an archive is not testable. Can this behavior be changed? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ARQ-2143) Deployments that expect exceptions are not testable.

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-2143?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak updated ARQ-2143: -------------------------------- Fix Version/s: 1.1.14.Final > Deployments that expect exceptions are not testable. > ---------------------------------------------------- > > Key: ARQ-2143 > URL: https://issues.jboss.org/browse/ARQ-2143 > Project: Arquillian > Issue Type: Bug > Reporter: John Ament > Fix For: 1.1.14.Final > > > Microprofile has some spec tests that rely on throwing exceptions on deployment. https://github.com/eclipse/microprofile-jwt-auth/blob/master/tck/src/test... is one such test (ignore that it doesn't extend Arquillian). > The problem is that its not the code in the package that generates the exception, but classes added via an ArchiveProcessor, e.g. a CDI extension, that will generate the exception. > I'm not sure the reasoning behind this behavior, but I don't see why {{ShouldThrowException}} implies that an archive is not testable. Can this behavior be changed? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues November 2017