From issues at jboss.org Thu Feb 1 01:09:00 2018 From: issues at jboss.org (Dipak Pawar (JIRA)) Date: Thu, 1 Feb 2018 01:09:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2144) Incomplete arquillian-testng.jar for TestNG 6.10+ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13527014#comment-13527014 ] Dipak Pawar commented on ARQ-2144: ---------------------------------- We found the root cause of this issue. TestNG has some issue while packaging there jars. You can find all the details at https://github.com/cbeust/testng/issues/1677 and https://github.com/cbeust/jcommander/issues/430. We have to wait TestNG fixes this in upstream. If you are blocked with this issue then for the time being as workaround just "org.testng:testng" dependency as library while creating archive using srinkwrap in it,. Something like {code:java} @Deployment public static WebArchive createDeployment() { final PomEquippedResolveStage pomEquippedResolveStage = Maven.resolver().loadPomFromFile("pom.xml"); File[] mavenFiles = pomEquippedResolveStage.importRuntimeDependencies().resolve() .withTransitivity().asFile(); return ShrinkWrap.create(WebArchive.class).addPackage("application.rest").addPackage("application") .addAsLibraries(mavenFiles) .addAsLibraries(pomEquippedResolveStage.resolve("org.testng:testng").withTransitivity().asFile()); } {code} > Incomplete arquillian-testng.jar for TestNG 6.10+ > ------------------------------------------------- > > Key: ARQ-2144 > URL: https://issues.jboss.org/browse/ARQ-2144 > Project: Arquillian > Issue Type: Bug > Components: Base Implementation, Daemon > Affects Versions: 1.1.13.Final > Environment: jdk1.8.0_141 OSX > Reporter: Scott Stark > Assignee: Andrew Rubinger > Priority: Critical > Attachments: TestNGWorkaround.java > > > I have created a simple cdi test that illustrates a problem I'm seeing with TestNG based remote tests running in Wildfly-Swarm. The issue is that the arquillian-testng.jar that is attached to the test WebArchive is missing the majority of TestNG classes, and so the test fails to load in the container runtime. > I have created a https://github.com/starksm64/arq-testnq-tests repository with two tests that illustrate the problem. > There is a ex.ExceptionTest that illustrates the inability to deploy the test due to NoClassDefFoundError: > {noformat} > 2017-09-20 16:49:37,560 ERROR [stderr] (nioEventLoopGroup-3-1) java.lang.NoClassDefFoundError: Failed to link ex/ExceptionTest (Module "deployment.exTest.war:main" from Service Module Loader): Failed to link org/jboss/arquillian/testng/Arquillian (Module "deployment.exTest.war:main" from Service Module Loader): Failed to link org/testng/IHookable (Module "deployment.exTest.war:main" from Service Module Loader): org/testng/ITestNGListener > 2017-09-20 16:49:37,560 ERROR [stderr] (nioEventLoopGroup-3-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > 2017-09-20 16:49:37,560 ERROR [stderr] (nioEventLoopGroup-3-1) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > 2017-09-20 16:49:37,560 ERROR [stderr] (nioEventLoopGroup-3-1) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > 2017-09-20 16:49:37,560 ERROR [stderr] (nioEventLoopGroup-3-1) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > 2017-09-20 16:49:37,561 ERROR [stderr] (nioEventLoopGroup-3-1) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:446) > 2017-09-20 16:49:37,561 ERROR [stderr] (nioEventLoopGroup-3-1) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274) > 2017-09-20 16:49:37,561 ERROR [stderr] (nioEventLoopGroup-3-1) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78) > 2017-09-20 16:49:37,561 ERROR [stderr] (nioEventLoopGroup-3-1) at org.jboss.modules.Module.loadModuleClass(Module.java:606) > 2017-09-20 16:49:37,561 ERROR [stderr] (nioEventLoopGroup-3-1) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) > 2017-09-20 16:49:37,561 ERROR [stderr] (nioEventLoopGroup-3-1) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) > 2017-09-20 16:49:37,561 ERROR [stderr] (nioEventLoopGroup-3-1) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) > 2017-09-20 16:49:37,561 ERROR [stderr] (nioEventLoopGroup-3-1) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) > 2017-09-20 16:49:37,562 ERROR [stderr] (nioEventLoopGroup-3-1) at org.wildfly.swarm.arquillian.daemon.TestRunner.executeTest(TestRunner.java:45) > 2017-09-20 16:49:37,562 ERROR [stderr] (nioEventLoopGroup-3-1) at org.wildfly.swarm.arquillian.daemon.server.Server.executeTest(Server.java:250) > 2017-09-20 16:49:37,562 ERROR [stderr] (nioEventLoopGroup-3-1) at org.wildfly.swarm.arquillian.daemon.server.Server$StringCommandHandler.channelRead0(Server.java:361) > 2017-09-20 16:49:37,562 ERROR [stderr] (nioEventLoopGroup-3-1) at org.wildfly.swarm.arquillian.daemon.server.Server$StringCommandHandler.channelRead0(Server.java:303) > 2017-09-20 16:49:37,562 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105) > 2017-09-20 16:49:37,562 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318) > 2017-09-20 16:49:37,562 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304) > 2017-09-20 16:49:37,562 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) > 2017-09-20 16:49:37,562 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318) > 2017-09-20 16:49:37,562 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304) > 2017-09-20 16:49:37,562 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:276) > 2017-09-20 16:49:37,562 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:263) > 2017-09-20 16:49:37,563 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318) > 2017-09-20 16:49:37,563 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304) > 2017-09-20 16:49:37,563 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846) > 2017-09-20 16:49:37,563 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131) > 2017-09-20 16:49:37,563 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) > 2017-09-20 16:49:37,563 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) > 2017-09-20 16:49:37,563 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) > 2017-09-20 16:49:37,563 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) > 2017-09-20 16:49:37,563 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) > 2017-09-20 16:49:37,564 ERROR [stderr] (nioEventLoopGroup-3-1) at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137) > 2017-09-20 16:49:37,564 ERROR [stderr] (nioEventLoopGroup-3-1) at java.lang.Thread.run(Thread.java:748) > {noformat} > The test includes a TestNGArchiveProcessor AuxiliaryArchiveProcessor implementation that dumps out the arquillian-testng.jar seen in the WebArchive. It shows only the following org.testng package classes when run form within the Intellij IDEA IDE: > {noformat} > *-testng.jar contents: arquillian-testng.jar: > /org/ > /org/testng/ > /org/testng/IDEARemoteTestNG.class > /org/testng/IDEATestNGConfigurationListener.class > /org/testng/IDEATestNGInvokedMethodListener.class > /org/testng/IDEATestNGListener.class > /org/testng/IDEATestNGRemoteListener$DelegatedResult.class > /org/testng/IDEATestNGRemoteListener$ExposedTestResult.class > /org/testng/IDEATestNGRemoteListener.class > /org/testng/IDEATestNGSuiteListener.class > /org/testng/IDEATestNGTestListener.class > /org/testng/MapSerializerUtil$1.class > /org/testng/MapSerializerUtil$EscapeInfoProvider.class > /org/testng/MapSerializerUtil.class > /org/testng/RemoteTestNGStarter.class > /org/testng/TestNGExpectedPatterns.class > /org/testng/TestNGForkedSplitter.class > /org/testng/TestNGForkedStarter.class > /org/testng/TestNGTestDiscoveryListener.class > /org/testng/TestNGXmlSuiteHelper$Logger$1.class > /org/testng/TestNGXmlSuiteHelper$Logger.class > /org/testng/TestNGXmlSuiteHelper.class > {noformat} > When run from the command line the arquillian-testng.jar contains no org.testng package classes. > The underlying problem seems to be how the org.jboss.shrinkwrap.impl.base.URLPackageScanner includes package classes. I have a simple arq.URLPackageScannerTest in the that illustrates how URLPackageScanner fails to located org.testng classes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Feb 1 03:13:00 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Thu, 1 Feb 2018 03:13:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2170) RulesEnricher doubles each test enrichment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13527041#comment-13527041 ] Matous Jobanek commented on ARQ-2170: ------------------------------------- Hi, thanks for reporting this issue. > 1. RulesEnricher is not implementor of TestEnricher, so it cannot be overrided through LoadableExtension. The {{RulesEnricher}} cannot be an implementation of the {{TestEnricher}} because {{TestEnrichers}} are called in a later phase than the rules are created. That's why it is an observer that observes the event {{RulesEnrichment}} that is invoked before the other test enrichers. For more information see this issue https://issues.jboss.org/browse/ARQ-2034 > 2. RulesEnricher#enrichRulesAndTestInstance adds into collection toEnrich test instance: It is known that it does the double enrichment of the test instances, unfortunately, it is there for a purpose. The rules can be created inside of the test classes as an anonymous class that is using fields from the test class itself: {code:java} @ArquillianResource URL url; @Rule public TestRule rule = new TestRule() { public Statement apply(final Statement base, Description description) { doSomethingWithUrl(url); return new Statement() { @Override public void evaluate() throws Throwable { base.evaluate(); } }; } }; {code} For this purpose, it is necessary to inject the fields also into the test class. The second enrichment is then performed in the standard enrichment phase. > RulesEnricher doubles each test enrichment > ------------------------------------------ > > Key: ARQ-2170 > URL: https://issues.jboss.org/browse/ARQ-2170 > Project: Arquillian > Issue Type: Bug > Components: core > Environment: arquillian-junit-core-1.1.11.Final (all versions affected) > Reporter: kostd kostd > > RulesEnricher created in ARQ-1954 > 1. RulesEnricher is not implementor of TestEnricher, so it cannot be overrided through LoadableExtension. > 2. RulesEnricher#enrichRulesAndTestInstance adds into collection toEnrich test instance: > {code} > toEnrich.add(event.getTestInstance()); > {code} > https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/RulesEnricher.java > So, if MyTest have`nt field rules, will be only one MyTest enrichment. If MyTest contains one or more test rule, will be two MyTest enrichments. > Each testEnrichment of MyTest do a soap call to server to prepare data for test. It is very important to me, one or two soap call will happen. > How can I change this behaviour? -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Feb 1 07:01:00 2018 From: issues at jboss.org (kostd kostd (JIRA)) Date: Thu, 1 Feb 2018 07:01:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2170) RulesEnricher doubles each test enrichment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13527191#comment-13527191 ] kostd kostd commented on ARQ-2170: ---------------------------------- [~mjobanek], thanks for your answer. So, if both items are by design, can you provide some other spi to override RulesEnricher or yet another way to remove unnecessary (in some cases) second enrichment? For example, we use both enrichers and rules, but our rules agreed if testclass-fields will be null. > RulesEnricher doubles each test enrichment > ------------------------------------------ > > Key: ARQ-2170 > URL: https://issues.jboss.org/browse/ARQ-2170 > Project: Arquillian > Issue Type: Bug > Components: core > Environment: arquillian-junit-core-1.1.11.Final (all versions affected) > Reporter: kostd kostd > > RulesEnricher created in ARQ-1954 > 1. RulesEnricher is not implementor of TestEnricher, so it cannot be overrided through LoadableExtension. > 2. RulesEnricher#enrichRulesAndTestInstance adds into collection toEnrich test instance: > {code} > toEnrich.add(event.getTestInstance()); > {code} > https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/RulesEnricher.java > So, if MyTest have`nt field rules, will be only one MyTest enrichment. If MyTest contains one or more test rule, will be two MyTest enrichments. > Each testEnrichment of MyTest do a soap call to server to prepare data for test. It is very important to me, one or two soap call will happen. > How can I change this behaviour? -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Feb 2 07:46:00 2018 From: issues at jboss.org (Alex Soto (JIRA)) Date: Fri, 2 Feb 2018 07:46:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2173) Create of SPI for auto-deployment feature In-Reply-To: References: Message-ID: Alex Soto created ARQ-2173: ------------------------------ Summary: Create of SPI for auto-deployment feature Key: ARQ-2173 URL: https://issues.jboss.org/browse/ARQ-2173 Project: Arquillian Issue Type: Enhancement Components: Base Implementation Reporter: Alex Soto Creates a Java Service (SPI) to allow developers hook into deployment process and be able to generate its own automation process for creating the deployment archive instead of relying on method annotated with @Deployment. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Feb 2 07:46:00 2018 From: issues at jboss.org (Alex Soto (JIRA)) Date: Fri, 2 Feb 2018 07:46:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2173) Create of SPI for auto-deployment feature In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Soto updated ARQ-2173: --------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/154 > Create of SPI for auto-deployment feature > ----------------------------------------- > > Key: ARQ-2173 > URL: https://issues.jboss.org/browse/ARQ-2173 > Project: Arquillian > Issue Type: Enhancement > Components: Base Implementation > Reporter: Alex Soto > > Creates a Java Service (SPI) to allow developers hook into deployment process and be able to generate its own automation process for creating the deployment archive instead of relying on method annotated with @Deployment. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 04:29:00 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 5 Feb 2018 04:29:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-515) Update Arquillian core to 1.2.0.Final In-Reply-To: References: Message-ID: Matous Jobanek created ARQGRA-515: ------------------------------------- Summary: Update Arquillian core to 1.2.0.Final Key: ARQGRA-515 URL: https://issues.jboss.org/browse/ARQGRA-515 Project: Arquillian Graphene Issue Type: Component Upgrade Components: core Affects Versions: 2.3.2 Reporter: Matous Jobanek Assignee: Matous Jobanek Fix For: 2.3.3 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 06:22:00 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 5 Feb 2018 06:22:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2174) Provide a way of observing Arqullian events within a test class In-Reply-To: References: Message-ID: Matous Jobanek created ARQ-2174: ----------------------------------- Summary: Provide a way of observing Arqullian events within a test class Key: ARQ-2174 URL: https://issues.jboss.org/browse/ARQ-2174 Project: Arquillian Issue Type: Enhancement Components: core Reporter: Matous Jobanek Assignee: Matous Jobanek Fix For: 1.2.2.Final Provide some way to observe Arquillian events from the test class or some external class defined by an annotation (eg. {{Observer}}). This observer should be related only to the specific test class and should behave as any other Arquillian observer (supporting injection). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 06:24:00 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 5 Feb 2018 06:24:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2174) Provide a way of observing Arqullian events within a test class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2174: -------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-core/pull/161 > Provide a way of observing Arqullian events within a test class > --------------------------------------------------------------- > > Key: ARQ-2174 > URL: https://issues.jboss.org/browse/ARQ-2174 > Project: Arquillian > Issue Type: Enhancement > Components: core > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: 1.2.2.Final > > > Provide some way to observe Arquillian events from the test class or some external class defined by an annotation (eg. {{Observer}}). This observer should be related only to the specific test class and should behave as any other Arquillian observer (supporting injection). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 06:57:00 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 5 Feb 2018 06:57:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2170) RulesEnricher doubles each test enrichment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13528351#comment-13528351 ] Matous Jobanek commented on ARQ-2170: ------------------------------------- There is a way to disable the functionality of the {{RulesEnricher}} - you need to create an Arquillian extension with an interceptor where you don't proceed the event {{RulesEnrichment}}. Interceptor is an observer, but instead of observing the event itself, you observe the context of the event: {code:java} public void observe(@Observes(precedence = 100) EventContext event) { {code} If the {{event.proceed()}} is not called within this method, then the event flow is stopped, and thus the observer {{RulesEnricher}} is not invoked. Currently, it is necessary to create an Arquillian extension using SPI for it - from the next version of Arquillian core it should be possible to do it specifically just for one test class inside of your test suite using an annotation {{@Observer}}. For more information see: https://github.com/arquillian/arquillian-core/pull/161 https://issues.jboss.org/browse/ARQ-2174 I hope that this will help. > RulesEnricher doubles each test enrichment > ------------------------------------------ > > Key: ARQ-2170 > URL: https://issues.jboss.org/browse/ARQ-2170 > Project: Arquillian > Issue Type: Bug > Components: core > Environment: arquillian-junit-core-1.1.11.Final (all versions affected) > Reporter: kostd kostd > > RulesEnricher created in ARQ-1954 > 1. RulesEnricher is not implementor of TestEnricher, so it cannot be overrided through LoadableExtension. > 2. RulesEnricher#enrichRulesAndTestInstance adds into collection toEnrich test instance: > {code} > toEnrich.add(event.getTestInstance()); > {code} > https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/RulesEnricher.java > So, if MyTest have`nt field rules, will be only one MyTest enrichment. If MyTest contains one or more test rule, will be two MyTest enrichments. > Each testEnrichment of MyTest do a soap call to server to prepare data for test. It is very important to me, one or two soap call will happen. > How can I change this behaviour? -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 10:41:00 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 5 Feb 2018 10:41:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2174) Provide a way of observing Arqullian events within a test class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2174: -------------------------------- Status: Pull Request Sent (was: Open) > Provide a way of observing Arqullian events within a test class > --------------------------------------------------------------- > > Key: ARQ-2174 > URL: https://issues.jboss.org/browse/ARQ-2174 > Project: Arquillian > Issue Type: Enhancement > Components: core > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: 1.2.2.Final > > > Provide some way to observe Arquillian events from the test class or some external class defined by an annotation (eg. {{Observer}}). This observer should be related only to the specific test class and should behave as any other Arquillian observer (supporting injection). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 10:41:00 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 5 Feb 2018 10:41:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2174) Provide a way of observing Arqullian events within a test class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2174: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Provide a way of observing Arqullian events within a test class > --------------------------------------------------------------- > > Key: ARQ-2174 > URL: https://issues.jboss.org/browse/ARQ-2174 > Project: Arquillian > Issue Type: Enhancement > Components: core > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: 1.2.2.Final > > > Provide some way to observe Arquillian events from the test class or some external class defined by an annotation (eg. {{Observer}}). This observer should be related only to the specific test class and should behave as any other Arquillian observer (supporting injection). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 10:42:01 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 5 Feb 2018 10:42:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2174) Provide a way of observing Arqullian events within a test class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2174: -------------------------------- Component/s: Base Implementation (was: core) > Provide a way of observing Arqullian events within a test class > --------------------------------------------------------------- > > Key: ARQ-2174 > URL: https://issues.jboss.org/browse/ARQ-2174 > Project: Arquillian > Issue Type: Enhancement > Components: Base Implementation > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: 1.2.2.Final > > > Provide some way to observe Arquillian events from the test class or some external class defined by an annotation (eg. {{Observer}}). This observer should be related only to the specific test class and should behave as any other Arquillian observer (supporting injection). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 10:42:01 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 5 Feb 2018 10:42:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2173) Create of SPI for auto-deployment feature In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak reassigned ARQ-2173: ----------------------------------- Assignee: Alex Soto > Create of SPI for auto-deployment feature > ----------------------------------------- > > Key: ARQ-2173 > URL: https://issues.jboss.org/browse/ARQ-2173 > Project: Arquillian > Issue Type: Enhancement > Components: Base Implementation > Reporter: Alex Soto > Assignee: Alex Soto > Fix For: 1.2.2.Final > > > Creates a Java Service (SPI) to allow developers hook into deployment process and be able to generate its own automation process for creating the deployment archive instead of relying on method annotated with @Deployment. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 10:42:01 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 5 Feb 2018 10:42:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2173) Create of SPI for auto-deployment feature In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2173: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Create of SPI for auto-deployment feature > ----------------------------------------- > > Key: ARQ-2173 > URL: https://issues.jboss.org/browse/ARQ-2173 > Project: Arquillian > Issue Type: Enhancement > Components: Base Implementation > Reporter: Alex Soto > Assignee: Alex Soto > > Creates a Java Service (SPI) to allow developers hook into deployment process and be able to generate its own automation process for creating the deployment archive instead of relying on method annotated with @Deployment. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 10:42:01 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 5 Feb 2018 10:42:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2173) Create of SPI for auto-deployment feature In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2173: -------------------------------- Fix Version/s: 1.2.2.Final > Create of SPI for auto-deployment feature > ----------------------------------------- > > Key: ARQ-2173 > URL: https://issues.jboss.org/browse/ARQ-2173 > Project: Arquillian > Issue Type: Enhancement > Components: Base Implementation > Reporter: Alex Soto > Assignee: Alex Soto > Fix For: 1.2.2.Final > > > Creates a Java Service (SPI) to allow developers hook into deployment process and be able to generate its own automation process for creating the deployment archive instead of relying on method annotated with @Deployment. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 10:42:02 2018 From: issues at jboss.org (kostd kostd (JIRA)) Date: Mon, 5 Feb 2018 10:42:02 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2170) RulesEnricher doubles each test enrichment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kostd kostd resolved ARQ-2170. ------------------------------ Resolution: Explained [~mjobanek], many thanks, we will try to intercept! closing this issue as "by design" > RulesEnricher doubles each test enrichment > ------------------------------------------ > > Key: ARQ-2170 > URL: https://issues.jboss.org/browse/ARQ-2170 > Project: Arquillian > Issue Type: Bug > Components: core > Environment: arquillian-junit-core-1.1.11.Final (all versions affected) > Reporter: kostd kostd > > RulesEnricher created in ARQ-1954 > 1. RulesEnricher is not implementor of TestEnricher, so it cannot be overrided through LoadableExtension. > 2. RulesEnricher#enrichRulesAndTestInstance adds into collection toEnrich test instance: > {code} > toEnrich.add(event.getTestInstance()); > {code} > https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/RulesEnricher.java > So, if MyTest have`nt field rules, will be only one MyTest enrichment. If MyTest contains one or more test rule, will be two MyTest enrichments. > Each testEnrichment of MyTest do a soap call to server to prepare data for test. It is very important to me, one or two soap call will happen. > How can I change this behaviour? -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 10:59:01 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 5 Feb 2018 10:59:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2173) Create of SPI for auto-deployment feature In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2173: -------------------------------- Fix Version/s: 1.3.0.Final (was: 1.2.2.Final) > Create of SPI for auto-deployment feature > ----------------------------------------- > > Key: ARQ-2173 > URL: https://issues.jboss.org/browse/ARQ-2173 > Project: Arquillian > Issue Type: Enhancement > Components: Base Implementation > Reporter: Alex Soto > Assignee: Alex Soto > Fix For: 1.3.0.Final > > > Creates a Java Service (SPI) to allow developers hook into deployment process and be able to generate its own automation process for creating the deployment archive instead of relying on method annotated with @Deployment. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 5 11:00:01 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 5 Feb 2018 11:00:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2174) Provide a way of observing Arqullian events within a test class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2174: -------------------------------- Fix Version/s: 1.3.0.Final (was: 1.2.2.Final) > Provide a way of observing Arqullian events within a test class > --------------------------------------------------------------- > > Key: ARQ-2174 > URL: https://issues.jboss.org/browse/ARQ-2174 > Project: Arquillian > Issue Type: Enhancement > Components: Base Implementation > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: 1.3.0.Final > > > Provide some way to observe Arquillian events from the test class or some external class defined by an annotation (eg. {{Observer}}). This observer should be related only to the specific test class and should behave as any other Arquillian observer (supporting injection). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Feb 6 02:17:02 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 6 Feb 2018 02:17:02 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2170) RulesEnricher doubles each test enrichment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek reassigned ARQ-2170: ----------------------------------- Assignee: Matous Jobanek > RulesEnricher doubles each test enrichment > ------------------------------------------ > > Key: ARQ-2170 > URL: https://issues.jboss.org/browse/ARQ-2170 > Project: Arquillian > Issue Type: Bug > Components: core > Environment: arquillian-junit-core-1.1.11.Final (all versions affected) > Reporter: kostd kostd > Assignee: Matous Jobanek > > RulesEnricher created in ARQ-1954 > 1. RulesEnricher is not implementor of TestEnricher, so it cannot be overrided through LoadableExtension. > 2. RulesEnricher#enrichRulesAndTestInstance adds into collection toEnrich test instance: > {code} > toEnrich.add(event.getTestInstance()); > {code} > https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/RulesEnricher.java > So, if MyTest have`nt field rules, will be only one MyTest enrichment. If MyTest contains one or more test rule, will be two MyTest enrichments. > Each testEnrichment of MyTest do a soap call to server to prepare data for test. It is very important to me, one or two soap call will happen. > How can I change this behaviour? -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Feb 9 03:19:01 2018 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Fri, 9 Feb 2018 03:19:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2162) New release for wlp-managed container (with support for multi-app verification before test app deployment) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-2162 started by Gerhard Poul. ----------------------------------------- > New release for wlp-managed container (with support for multi-app verification before test app deployment) > ---------------------------------------------------------------------------------------------------------- > > Key: ARQ-2162 > URL: https://issues.jboss.org/browse/ARQ-2162 > Project: Arquillian > Issue Type: Release > Components: WebSphere Containers > Reporter: Charles Tian > Assignee: Gerhard Poul > > I'm a developer at IBM currently working on some updates for the Arquillian WLP managed container. I have some improvements which I'm planning to push out in the next couple of weeks. > Once these changed get reviewed and merged, could we make a new release for the WLP managed container on Maven Central? The current version is 1.0.0.Beta2 and was released almost three years ago (Jan. 2015). Since then, there have been many updates made to the container (including the changes that I will be providing) that are not part of any release. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Feb 18 04:13:00 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sun, 18 Feb 2018 04:13:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2020) wlp-remote arquillian support for wlp server assembly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2020: -------------------------------- Fix Version/s: was_1.0.0.CR1 > wlp-remote arquillian support for wlp server assembly > ----------------------------------------------------- > > Key: ARQ-2020 > URL: https://issues.jboss.org/browse/ARQ-2020 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: Gerhard Poul > Assignee: Gerhard Poul > Fix For: was_1.0.0.CR1 > > > Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: > https://github.com/WASdev/ci.maven#liberty-assembly > It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. > This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Feb 18 04:13:00 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sun, 18 Feb 2018 04:13:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2020) wlp-remote arquillian support for wlp server assembly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2020: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > wlp-remote arquillian support for wlp server assembly > ----------------------------------------------------- > > Key: ARQ-2020 > URL: https://issues.jboss.org/browse/ARQ-2020 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: Gerhard Poul > Assignee: Gerhard Poul > Fix For: was_1.0.0.CR1 > > > Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: > https://github.com/WASdev/ci.maven#liberty-assembly > It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. > This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Feb 18 04:14:00 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sun, 18 Feb 2018 04:14:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2051) Add ability to add localconnector feature automatically to server.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2051: -------------------------------- Fix Version/s: was_1.0.0.CR1 > Add ability to add localconnector feature automatically to server.xml > --------------------------------------------------------------------- > > Key: ARQ-2051 > URL: https://issues.jboss.org/browse/ARQ-2051 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Affects Versions: was_1.0.0.Beta2 > Reporter: arjan tijms > Assignee: Gerhard Poul > Fix For: was_1.0.0.CR1 > > > For the managed container for Liberty to connect to a liberty instance, the {{localConnector-1.0}} feature needs to be present in {{server.xml}}. > This is somewhat of an obstacle when using a CI managed Liberty, where a Liberty instance is downloaded and installed from Maven during the test. Following the work done in ARQ-1729 it should be relatively easy to add this {{localConnector-1.0}} feature to {{server.xml}}. > I would like to propose adding a new boolean to the configuration for the managed Liberty container, and when set to true the Arquillian container will add the mentioned feature and will thus be able to start Liberty without requiring the user to modify the installation first. > (I'll look into doing a PR for this) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Feb 18 04:14:00 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sun, 18 Feb 2018 04:14:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2121) wlp-managed extension In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2121: -------------------------------- Fix Version/s: was_1.0.0.CR1 (was: was_1.0.0.next) > wlp-managed extension > --------------------- > > Key: ARQ-2121 > URL: https://issues.jboss.org/browse/ARQ-2121 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Affects Versions: 1.0.0.Beta1 > Reporter: Christian Connert > Assignee: Gerhard Poul > Fix For: was_1.0.0.CR1 > > Attachments: wlp.patch > > > Hi guys, > I did some work on the wlp-managed container which I would like to share with you: > # Support for multiple JVM arguments > # Support for different context roots (multi war projects) > # Security configuration for deployed applications > # And last but not least fail-safe undeployment (xml) -> seems to be an issue when running the wlp within windows and the Oracle JVM > Hopfully you find my contribution usefule and will apply the attached patch. > Cheers -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Feb 18 04:15:00 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sun, 18 Feb 2018 04:15:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2152) Add support for setting 'apiTypeVisibility' in Websphere Liberty Application Server Container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2152: -------------------------------- Affects Version/s: (was: was_1.0.0.next) > 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 > 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-managed-8.5 > Reporter: Gordon Hutchison > Assignee: Gerhard Poul > Priority: Minor > Fix For: was_1.0.0.CR1 > > > (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 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 xml and spec, ibm-api, third-party 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.websphere.wlp.doc/ae/twlp_classloader_3p_apis.html > 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-managed-8.5/src/main/java/org/jboss/arquillian/container/was/wlp_managed_8_5 > I have checked with Kevin that he is happy for me to do this: > (On IBM Sametime) > gordon_hutchison at 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) From issues at jboss.org Sun Feb 18 04:15:00 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sun, 18 Feb 2018 04:15:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2152) Add support for setting 'apiTypeVisibility' in Websphere Liberty Application Server Container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2152: -------------------------------- Fix Version/s: was_1.0.0.CR1 > 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 > 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-managed-8.5 > Reporter: Gordon Hutchison > Assignee: Gerhard Poul > Priority: Minor > Fix For: was_1.0.0.CR1 > > > (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 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 xml and spec, ibm-api, third-party 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.websphere.wlp.doc/ae/twlp_classloader_3p_apis.html > 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-managed-8.5/src/main/java/org/jboss/arquillian/container/was/wlp_managed_8_5 > I have checked with Kevin that he is happy for me to do this: > (On IBM Sametime) > gordon_hutchison at 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) From issues at jboss.org Sun Feb 18 04:15:00 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sun, 18 Feb 2018 04:15:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2001) Log status code in WLPRestClient.isServerUp() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2001: -------------------------------- Fix Version/s: was_1.0.0.CR1 (was: was_1.0.0.next) > Log status code in WLPRestClient.isServerUp() > --------------------------------------------- > > Key: ARQ-2001 > URL: https://issues.jboss.org/browse/ARQ-2001 > Project: Arquillian > Issue Type: Enhancement > Components: WebSphere Containers > Reporter: Paul Holding > Assignee: Gerhard Poul > Fix For: was_1.0.0.CR1 > > > The WLPRestClient.isServerUp() method doesn't log the status code returned when the following line of code is executed > {code:java} > HttpResponse result = executor.execute(Request.Get(hostName)).returnResponse(); > {code} > The lack of logging makes is impossible to tell why the isServerUp() check failure occurred and the only information returned is a LifecycleException thrown by WLPRemoteContainer with the text "Remote server is not started". This can be misleading as the server may be up but something else is wrong such as an authentication failure. > Adding something similar to the logging in WLPRestClient.deploy(File archive) would allow the HTTP status code to be recorded and make troubleshooting a lot easier. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Feb 18 04:16:00 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sun, 18 Feb 2018 04:16:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2131) Fix for multiple JVM arguments not released In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2131: -------------------------------- Fix Version/s: was_1.0.0.CR1 (was: was_1.0.0.next) > Fix for multiple JVM arguments not released > ------------------------------------------- > > Key: ARQ-2131 > URL: https://issues.jboss.org/browse/ARQ-2131 > Project: Arquillian > Issue Type: Bug > Components: WebSphere Containers > Environment: {code}arquillian-container-was-1.0.0.Beta2{code} > {{arquillian.xml}} snippet: > {code:xml} > > xml > -Dsetting1=x -Dsetting2=y > > {code} > Reporter: Benjamin Marwell > Assignee: Gerhard Poul > Fix For: was_1.0.0.CR1 > > > Hello, > h2. expected output > Process started with (from Debug): > {{FINER: Starting server with command: [java, -Dsetting1=x, -Dsetting2=y, -javaagent:lib/bootstrap-agent.jar, -jar, lib/ws-launch.jar, defaultServer]}} > h2. actual output > note the missing comma betweed setting1 and setting2: > {{FINER: Starting server with command: [java, -Dsetting1=x -Dsetting2=y, -javaagent:lib/bootstrap-agent.jar, -jar, lib/ws-launch.jar, defaultServer]}} > h2. Solution > Already exists. This commit is currently not in a release: > https://github.com/arquillian/arquillian-container-was/commit/a1a77fe92418f49943a97a57a4dd1ff7ebc2bd25#diff-957685487719c29ce4c464fc2ec9cf39 > What can't be seen from here: this commit is needed to have multiple JVM args. Otherwise all jvm args are concatenated into a single String. > So, the bug is fixed in trunk, but not released. > h2. Proposed test case > It is also missing a test case. > Please add a test case with two or more {{-D}}-Parameters and check in your servlet if they are set. > Thank you very much! -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Feb 18 04:17:00 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sun, 18 Feb 2018 04:17:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2115) Create Arquillian adapter for WebSphere 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2115: -------------------------------- Fix Version/s: was_1.0.0.CR1 (was: was_1.0.0.next) > Create Arquillian adapter for WebSphere 9 > ----------------------------------------- > > Key: ARQ-2115 > URL: https://issues.jboss.org/browse/ARQ-2115 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: Mari?n Macik > Assignee: Gerhard Poul > Fix For: was_1.0.0.CR1 > > > Hi, guys, > I have created the Arquillian adapter for WebSphere 9. Here is the summary of the PR [1]: > \#### Short description of what this resolves: > Hi, guys, > my name is Marian Macik and I work at Red Hat as QE Engineer on [jBPM|https://github.com/kiegroup/jbpm] project. This PR introduces Arquillian container adapter for WebSphere 9. We have been using it at Red Hat in our QE automation for about two months without any issues. It is copied from adapter for WebSphere 8.5 (as WebSphere 8.5 was copied from WebSphere 8). There were only some minor changes when it comes to system paths pointing at WebSphere dependencies (jgss-provider and ws-admin-client). > However, since WebSphere 9, wsadmin is using jython27 by default. Jython21 is still supported and to use jython21, 'com.ibm.ws.admin.client.forJython21_9.0.jar' should be used. Moreover, the new wsadmin jar has additional libraries which are not used by Arquillian (such as Python JSR 223 implementation) and might cause issues when deploying and running tests. If this happens, simply override this property with jython21 jar: > {code} > -Dws_admin_client_jar_name=com.ibm.ws.admin.client.forJython21_9.0.jar > {code} > I added this property because the new jython27 wsadmin implementation was causing issues since it loaded unwanted classes on the classpath. Of course, by default the new jython27 wsadmin is used, override is optional. > I have also run the enclosed tests with my own arquillian.xml and they have passed. > Thanks, > Marian > [1] https://github.com/arquillian/arquillian-container-was/pull/29 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Feb 18 04:18:00 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Sun, 18 Feb 2018 04:18:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1756) wlp-managed arquillian support for wlp server assembly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-1756: -------------------------------- Fix Version/s: was_1.0.0.CR1 (was: was_1.0.0.next) > wlp-managed arquillian support for wlp server assembly > ------------------------------------------------------ > > Key: ARQ-1756 > URL: https://issues.jboss.org/browse/ARQ-1756 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: D K > Assignee: Gerhard Poul > Fix For: was_1.0.0.CR1 > > > Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: > https://github.com/WASdev/ci.maven#liberty-assembly > It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. > https://github.com/arquillian/arquillian-container-was/tree/master/wlp-managed-8.5 > This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Feb 21 05:28:00 2018 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 21 Feb 2018 05:28:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2175) DeploymentExceptionHandler can sometimes pass null to transformers In-Reply-To: References: Message-ID: Matej Novotny created ARQ-2175: ---------------------------------- Summary: DeploymentExceptionHandler can sometimes pass null to transformers Key: ARQ-2175 URL: https://issues.jboss.org/browse/ARQ-2175 Project: Arquillian Issue Type: Bug Components: core Affects Versions: 1.3.0.Final Reporter: Matej Novotny In some rare cases {{DeploymentExceptionHandler}} can pass null value to transformers, which isn't really useful. This can happen when the exception is {{DeploymentException}} which has no cause (or has itself set as cause). E.g. [this code|https://github.com/arquillian/arquillian-core/blob/1.3.0.Final/container/impl-base/src/main/java/org/jboss/arquillian/container/impl/client/container/DeploymentExceptionHandler.java#L106-L108] can yield {{null}}. I came across this in combination with [wildfly-arquillian|https://github.com/wildfly/wildfly-arquillian] and certain Arq. interceptor ordering (so that this exception handler was called first and the exception wasn't wrapped yet). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Feb 21 05:28:00 2018 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 21 Feb 2018 05:28:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2175) DeploymentExceptionHandler can sometimes pass null to transformers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny reassigned ARQ-2175: ---------------------------------- Assignee: Matej Novotny > DeploymentExceptionHandler can sometimes pass null to transformers > ------------------------------------------------------------------ > > Key: ARQ-2175 > URL: https://issues.jboss.org/browse/ARQ-2175 > Project: Arquillian > Issue Type: Bug > Components: core > Affects Versions: 1.3.0.Final > Reporter: Matej Novotny > Assignee: Matej Novotny > > In some rare cases {{DeploymentExceptionHandler}} can pass null value to transformers, which isn't really useful. > This can happen when the exception is {{DeploymentException}} which has no cause (or has itself set as cause). E.g. [this code|https://github.com/arquillian/arquillian-core/blob/1.3.0.Final/container/impl-base/src/main/java/org/jboss/arquillian/container/impl/client/container/DeploymentExceptionHandler.java#L106-L108] can yield {{null}}. > I came across this in combination with [wildfly-arquillian|https://github.com/wildfly/wildfly-arquillian] and certain Arq. interceptor ordering (so that this exception handler was called first and the exception wasn't wrapped yet). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Feb 21 05:35:00 2018 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Wed, 21 Feb 2018 05:35:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2175) DeploymentExceptionHandler can sometimes pass null to transformers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny updated ARQ-2175: ------------------------------- Git Pull Request: https://github.com/arquillian/arquillian-core/pull/164 > DeploymentExceptionHandler can sometimes pass null to transformers > ------------------------------------------------------------------ > > Key: ARQ-2175 > URL: https://issues.jboss.org/browse/ARQ-2175 > Project: Arquillian > Issue Type: Bug > Components: core > Affects Versions: 1.3.0.Final > Reporter: Matej Novotny > Assignee: Matej Novotny > > In some rare cases {{DeploymentExceptionHandler}} can pass null value to transformers, which isn't really useful. > This can happen when the exception is {{DeploymentException}} which has no cause (or has itself set as cause). E.g. [this code|https://github.com/arquillian/arquillian-core/blob/1.3.0.Final/container/impl-base/src/main/java/org/jboss/arquillian/container/impl/client/container/DeploymentExceptionHandler.java#L106-L108] can yield {{null}}. > I came across this in combination with [wildfly-arquillian|https://github.com/wildfly/wildfly-arquillian] and certain Arq. interceptor ordering (so that this exception handler was called first and the exception wasn't wrapped yet). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Feb 21 08:18:00 2018 From: issues at jboss.org (Resat SABIQ (JIRA)) Date: Wed, 21 Feb 2018 08:18:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2176) JUnit tests under @Nested class are ignored In-Reply-To: References: Message-ID: Resat SABIQ created ARQ-2176: -------------------------------- Summary: JUnit tests under @Nested class are ignored Key: ARQ-2176 URL: https://issues.jboss.org/browse/ARQ-2176 Project: Arquillian Issue Type: Feature Request Affects Versions: 1.3.0.Final Reporter: Resat SABIQ Since tests under @Nested are ignored, i had to comment it out. // @Nested // class AfterX { @Test @InSequence(3) public void test3() throws Exception { // } @Test @InSequence(4) public void test4() throws Exception { // } // } -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Feb 22 04:22:00 2018 From: issues at jboss.org (Alex Soto (JIRA)) Date: Thu, 22 Feb 2018 04:22:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2177) Extend expression language in arquillian configuration In-Reply-To: References: Message-ID: Alex Soto created ARQ-2177: ------------------------------ Summary: Extend expression language in arquillian configuration Key: ARQ-2177 URL: https://issues.jboss.org/browse/ARQ-2177 Project: Arquillian Issue Type: Enhancement Reporter: Alex Soto Add ability to refer to a file being available in the project, but expended to the full path during test execution, so we can refer to it in a flexible way. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Feb 22 04:29:00 2018 From: issues at jboss.org (Alex Soto (JIRA)) Date: Thu, 22 Feb 2018 04:29:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2177) Extend expression language in arquillian configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Soto updated ARQ-2177: --------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-core/pull/162 > Extend expression language in arquillian configuration > ------------------------------------------------------ > > Key: ARQ-2177 > URL: https://issues.jboss.org/browse/ARQ-2177 > Project: Arquillian > Issue Type: Enhancement > Reporter: Alex Soto > > Add ability to refer to a file being available in the project, but expended to the full path during test execution, so we can refer to it in a flexible way. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Feb 22 04:32:00 2018 From: issues at jboss.org (Alex Soto (JIRA)) Date: Thu, 22 Feb 2018 04:32:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2177) Extend expression language in arquillian configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Soto updated ARQ-2177: --------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Upstream: https://github.com/arquillian/arquillian-core/commit/57e24170ba0bc98b4871eefc885a41d202a820b3 > Extend expression language in arquillian configuration > ------------------------------------------------------ > > Key: ARQ-2177 > URL: https://issues.jboss.org/browse/ARQ-2177 > Project: Arquillian > Issue Type: Enhancement > Reporter: Alex Soto > > Add ability to refer to a file being available in the project, but expended to the full path during test execution, so we can refer to it in a flexible way. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Feb 23 05:32:00 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 23 Feb 2018 05:32:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2178) Update Arquillian Core and Shrinkwrap dependencies In-Reply-To: References: Message-ID: Bartosz Majsak created ARQ-2178: ----------------------------------- Summary: Update Arquillian Core and Shrinkwrap dependencies Key: ARQ-2178 URL: https://issues.jboss.org/browse/ARQ-2178 Project: Arquillian Issue Type: Task Components: Tomcat Containers Reporter: Bartosz Majsak Priority: Minor -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Feb 23 05:33:00 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 23 Feb 2018 05:33:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2178) Update Arquillian Core and Shrinkwrap dependencies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak updated ARQ-2178: -------------------------------- Fix Version/s: tomcat_1.0.1.Final > Update Arquillian Core and Shrinkwrap dependencies > -------------------------------------------------- > > Key: ARQ-2178 > URL: https://issues.jboss.org/browse/ARQ-2178 > Project: Arquillian > Issue Type: Task > Components: Tomcat Containers > Reporter: Bartosz Majsak > Priority: Minor > Fix For: tomcat_1.0.1.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Feb 23 05:33:01 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Fri, 23 Feb 2018 05:33:01 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2178) Update Arquillian Core and Shrinkwrap dependencies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Majsak resolved ARQ-2178. --------------------------------- Resolution: Done > Update Arquillian Core and Shrinkwrap dependencies > -------------------------------------------------- > > Key: ARQ-2178 > URL: https://issues.jboss.org/browse/ARQ-2178 > Project: Arquillian > Issue Type: Task > Components: Tomcat Containers > Reporter: Bartosz Majsak > Priority: Minor > Fix For: tomcat_1.0.1.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 26 02:44:00 2018 From: issues at jboss.org (=?UTF-8?Q?Mari=C3=A1n_Macik_=28JIRA=29?=) Date: Mon, 26 Feb 2018 02:44:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2115) Create Arquillian adapter for WebSphere 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13537896#comment-13537896 ] Mari?n Macik commented on ARQ-2115: ----------------------------------- Hi, [~bmajsak], does it mean that WebSphere adapter has finally been released? > Create Arquillian adapter for WebSphere 9 > ----------------------------------------- > > Key: ARQ-2115 > URL: https://issues.jboss.org/browse/ARQ-2115 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: Mari?n Macik > Assignee: Gerhard Poul > Fix For: was_1.0.0.CR1 > > > Hi, guys, > I have created the Arquillian adapter for WebSphere 9. Here is the summary of the PR [1]: > \#### Short description of what this resolves: > Hi, guys, > my name is Marian Macik and I work at Red Hat as QE Engineer on [jBPM|https://github.com/kiegroup/jbpm] project. This PR introduces Arquillian container adapter for WebSphere 9. We have been using it at Red Hat in our QE automation for about two months without any issues. It is copied from adapter for WebSphere 8.5 (as WebSphere 8.5 was copied from WebSphere 8). There were only some minor changes when it comes to system paths pointing at WebSphere dependencies (jgss-provider and ws-admin-client). > However, since WebSphere 9, wsadmin is using jython27 by default. Jython21 is still supported and to use jython21, 'com.ibm.ws.admin.client.forJython21_9.0.jar' should be used. Moreover, the new wsadmin jar has additional libraries which are not used by Arquillian (such as Python JSR 223 implementation) and might cause issues when deploying and running tests. If this happens, simply override this property with jython21 jar: > {code} > -Dws_admin_client_jar_name=com.ibm.ws.admin.client.forJython21_9.0.jar > {code} > I added this property because the new jython27 wsadmin implementation was causing issues since it loaded unwanted classes on the classpath. Of course, by default the new jython27 wsadmin is used, override is optional. > I have also run the enclosed tests with my own arquillian.xml and they have passed. > Thanks, > Marian > [1] https://github.com/arquillian/arquillian-container-was/pull/29 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 26 02:46:00 2018 From: issues at jboss.org (=?UTF-8?Q?Mari=C3=A1n_Macik_=28JIRA=29?=) Date: Mon, 26 Feb 2018 02:46:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2115) Create Arquillian adapter for WebSphere 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13537896#comment-13537896 ] Mari?n Macik edited comment on ARQ-2115 at 2/26/18 2:45 AM: ------------------------------------------------------------ Hi, [~bmajsak], does it mean that WebSphere adapter has finally been released to the Maven repo? was (Author: mmacik): Hi, [~bmajsak], does it mean that WebSphere adapter has finally been released? > Create Arquillian adapter for WebSphere 9 > ----------------------------------------- > > Key: ARQ-2115 > URL: https://issues.jboss.org/browse/ARQ-2115 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: Mari?n Macik > Assignee: Gerhard Poul > Fix For: was_1.0.0.CR1 > > > Hi, guys, > I have created the Arquillian adapter for WebSphere 9. Here is the summary of the PR [1]: > \#### Short description of what this resolves: > Hi, guys, > my name is Marian Macik and I work at Red Hat as QE Engineer on [jBPM|https://github.com/kiegroup/jbpm] project. This PR introduces Arquillian container adapter for WebSphere 9. We have been using it at Red Hat in our QE automation for about two months without any issues. It is copied from adapter for WebSphere 8.5 (as WebSphere 8.5 was copied from WebSphere 8). There were only some minor changes when it comes to system paths pointing at WebSphere dependencies (jgss-provider and ws-admin-client). > However, since WebSphere 9, wsadmin is using jython27 by default. Jython21 is still supported and to use jython21, 'com.ibm.ws.admin.client.forJython21_9.0.jar' should be used. Moreover, the new wsadmin jar has additional libraries which are not used by Arquillian (such as Python JSR 223 implementation) and might cause issues when deploying and running tests. If this happens, simply override this property with jython21 jar: > {code} > -Dws_admin_client_jar_name=com.ibm.ws.admin.client.forJython21_9.0.jar > {code} > I added this property because the new jython27 wsadmin implementation was causing issues since it loaded unwanted classes on the classpath. Of course, by default the new jython27 wsadmin is used, override is optional. > I have also run the enclosed tests with my own arquillian.xml and they have passed. > Thanks, > Marian > [1] https://github.com/arquillian/arquillian-container-was/pull/29 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 26 02:46:00 2018 From: issues at jboss.org (=?UTF-8?Q?Mari=C3=A1n_Macik_=28JIRA=29?=) Date: Mon, 26 Feb 2018 02:46:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2115) Create Arquillian adapter for WebSphere 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13537896#comment-13537896 ] Mari?n Macik edited comment on ARQ-2115 at 2/26/18 2:45 AM: ------------------------------------------------------------ Hi, [~bmajsak], does it mean that WebSphere adapter has finally been released and deployed to the Maven repo? was (Author: mmacik): Hi, [~bmajsak], does it mean that WebSphere adapter has finally been released to the Maven repo? > Create Arquillian adapter for WebSphere 9 > ----------------------------------------- > > Key: ARQ-2115 > URL: https://issues.jboss.org/browse/ARQ-2115 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: Mari?n Macik > Assignee: Gerhard Poul > Fix For: was_1.0.0.CR1 > > > Hi, guys, > I have created the Arquillian adapter for WebSphere 9. Here is the summary of the PR [1]: > \#### Short description of what this resolves: > Hi, guys, > my name is Marian Macik and I work at Red Hat as QE Engineer on [jBPM|https://github.com/kiegroup/jbpm] project. This PR introduces Arquillian container adapter for WebSphere 9. We have been using it at Red Hat in our QE automation for about two months without any issues. It is copied from adapter for WebSphere 8.5 (as WebSphere 8.5 was copied from WebSphere 8). There were only some minor changes when it comes to system paths pointing at WebSphere dependencies (jgss-provider and ws-admin-client). > However, since WebSphere 9, wsadmin is using jython27 by default. Jython21 is still supported and to use jython21, 'com.ibm.ws.admin.client.forJython21_9.0.jar' should be used. Moreover, the new wsadmin jar has additional libraries which are not used by Arquillian (such as Python JSR 223 implementation) and might cause issues when deploying and running tests. If this happens, simply override this property with jython21 jar: > {code} > -Dws_admin_client_jar_name=com.ibm.ws.admin.client.forJython21_9.0.jar > {code} > I added this property because the new jython27 wsadmin implementation was causing issues since it loaded unwanted classes on the classpath. Of course, by default the new jython27 wsadmin is used, override is optional. > I have also run the enclosed tests with my own arquillian.xml and they have passed. > Thanks, > Marian > [1] https://github.com/arquillian/arquillian-container-was/pull/29 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 26 03:19:00 2018 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Mon, 26 Feb 2018 03:19:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2115) Create Arquillian adapter for WebSphere 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13537928#comment-13537928 ] Bartosz Majsak commented on ARQ-2115: ------------------------------------- AFAIK the only one we can officially release to Maven Central is based on open source Liberty Profile. The others you have to build yourself if you have WAS licensed. Maybe [~gpoul] can correct me if I'm wrong. > Create Arquillian adapter for WebSphere 9 > ----------------------------------------- > > Key: ARQ-2115 > URL: https://issues.jboss.org/browse/ARQ-2115 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: Mari?n Macik > Assignee: Gerhard Poul > Fix For: was_1.0.0.CR1 > > > Hi, guys, > I have created the Arquillian adapter for WebSphere 9. Here is the summary of the PR [1]: > \#### Short description of what this resolves: > Hi, guys, > my name is Marian Macik and I work at Red Hat as QE Engineer on [jBPM|https://github.com/kiegroup/jbpm] project. This PR introduces Arquillian container adapter for WebSphere 9. We have been using it at Red Hat in our QE automation for about two months without any issues. It is copied from adapter for WebSphere 8.5 (as WebSphere 8.5 was copied from WebSphere 8). There were only some minor changes when it comes to system paths pointing at WebSphere dependencies (jgss-provider and ws-admin-client). > However, since WebSphere 9, wsadmin is using jython27 by default. Jython21 is still supported and to use jython21, 'com.ibm.ws.admin.client.forJython21_9.0.jar' should be used. Moreover, the new wsadmin jar has additional libraries which are not used by Arquillian (such as Python JSR 223 implementation) and might cause issues when deploying and running tests. If this happens, simply override this property with jython21 jar: > {code} > -Dws_admin_client_jar_name=com.ibm.ws.admin.client.forJython21_9.0.jar > {code} > I added this property because the new jython27 wsadmin implementation was causing issues since it loaded unwanted classes on the classpath. Of course, by default the new jython27 wsadmin is used, override is optional. > I have also run the enclosed tests with my own arquillian.xml and they have passed. > Thanks, > Marian > [1] https://github.com/arquillian/arquillian-container-was/pull/29 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Feb 26 14:42:00 2018 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Mon, 26 Feb 2018 14:42:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2115) Create Arquillian adapter for WebSphere 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538459#comment-13538459 ] Gerhard Poul commented on ARQ-2115: ----------------------------------- Yes, [~bmajsak] is correct. That is the current situation. I've had a discussion with someone from IBM last week and we'll see whether this can be changed or not; if you're a licensed customer you're certainly more than welcome to point IBM development or your IBM account reps in my direction as well to get this pushed in the right direction, if this is important for you. > Create Arquillian adapter for WebSphere 9 > ----------------------------------------- > > Key: ARQ-2115 > URL: https://issues.jboss.org/browse/ARQ-2115 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: Mari?n Macik > Assignee: Gerhard Poul > Fix For: was_1.0.0.CR1 > > > Hi, guys, > I have created the Arquillian adapter for WebSphere 9. Here is the summary of the PR [1]: > \#### Short description of what this resolves: > Hi, guys, > my name is Marian Macik and I work at Red Hat as QE Engineer on [jBPM|https://github.com/kiegroup/jbpm] project. This PR introduces Arquillian container adapter for WebSphere 9. We have been using it at Red Hat in our QE automation for about two months without any issues. It is copied from adapter for WebSphere 8.5 (as WebSphere 8.5 was copied from WebSphere 8). There were only some minor changes when it comes to system paths pointing at WebSphere dependencies (jgss-provider and ws-admin-client). > However, since WebSphere 9, wsadmin is using jython27 by default. Jython21 is still supported and to use jython21, 'com.ibm.ws.admin.client.forJython21_9.0.jar' should be used. Moreover, the new wsadmin jar has additional libraries which are not used by Arquillian (such as Python JSR 223 implementation) and might cause issues when deploying and running tests. If this happens, simply override this property with jython21 jar: > {code} > -Dws_admin_client_jar_name=com.ibm.ws.admin.client.forJython21_9.0.jar > {code} > I added this property because the new jython27 wsadmin implementation was causing issues since it loaded unwanted classes on the classpath. Of course, by default the new jython27 wsadmin is used, override is optional. > I have also run the enclosed tests with my own arquillian.xml and they have passed. > Thanks, > Marian > [1] https://github.com/arquillian/arquillian-container-was/pull/29 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Feb 27 11:19:00 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 27 Feb 2018 11:19:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2177) Extend expression language in arquillian configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2177: -------------------------------- Fix Version/s: 1.4.0.Final > Extend expression language in arquillian configuration > ------------------------------------------------------ > > Key: ARQ-2177 > URL: https://issues.jboss.org/browse/ARQ-2177 > Project: Arquillian > Issue Type: Enhancement > Reporter: Alex Soto > Fix For: 1.4.0.Final > > > Add ability to refer to a file being available in the project, but expended to the full path during test execution, so we can refer to it in a flexible way. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Feb 27 11:19:00 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 27 Feb 2018 11:19:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2177) Extend expression language in arquillian configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek reassigned ARQ-2177: ----------------------------------- Assignee: Alex Soto > Extend expression language in arquillian configuration > ------------------------------------------------------ > > Key: ARQ-2177 > URL: https://issues.jboss.org/browse/ARQ-2177 > Project: Arquillian > Issue Type: Enhancement > Reporter: Alex Soto > Assignee: Alex Soto > Fix For: 1.4.0.Final > > > Add ability to refer to a file being available in the project, but expended to the full path during test execution, so we can refer to it in a flexible way. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Feb 27 11:19:00 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 27 Feb 2018 11:19:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2177) Extend expression language in arquillian configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek closed ARQ-2177. ------------------------------- > Extend expression language in arquillian configuration > ------------------------------------------------------ > > Key: ARQ-2177 > URL: https://issues.jboss.org/browse/ARQ-2177 > Project: Arquillian > Issue Type: Enhancement > Reporter: Alex Soto > Assignee: Alex Soto > Fix For: 1.4.0.Final > > > Add ability to refer to a file being available in the project, but expended to the full path during test execution, so we can refer to it in a flexible way. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Feb 27 11:20:00 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 27 Feb 2018 11:20:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2175) DeploymentExceptionHandler can sometimes pass null to transformers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2175: -------------------------------- Fix Version/s: 1.4.0.Final > DeploymentExceptionHandler can sometimes pass null to transformers > ------------------------------------------------------------------ > > Key: ARQ-2175 > URL: https://issues.jboss.org/browse/ARQ-2175 > Project: Arquillian > Issue Type: Bug > Components: core > Affects Versions: 1.3.0.Final > Reporter: Matej Novotny > Assignee: Matej Novotny > Fix For: 1.4.0.Final > > > In some rare cases {{DeploymentExceptionHandler}} can pass null value to transformers, which isn't really useful. > This can happen when the exception is {{DeploymentException}} which has no cause (or has itself set as cause). E.g. [this code|https://github.com/arquillian/arquillian-core/blob/1.3.0.Final/container/impl-base/src/main/java/org/jboss/arquillian/container/impl/client/container/DeploymentExceptionHandler.java#L106-L108] can yield {{null}}. > I came across this in combination with [wildfly-arquillian|https://github.com/wildfly/wildfly-arquillian] and certain Arq. interceptor ordering (so that this exception handler was called first and the exception wasn't wrapped yet). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Feb 27 11:20:00 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 27 Feb 2018 11:20:00 -0500 (EST) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2175) DeploymentExceptionHandler can sometimes pass null to transformers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek closed ARQ-2175. ------------------------------- Resolution: Done Pushed upstream in https://github.com/arquillian/arquillian-core/commit/d5f4f93661e57d3695fa806b37b104ff593fbe48 > DeploymentExceptionHandler can sometimes pass null to transformers > ------------------------------------------------------------------ > > Key: ARQ-2175 > URL: https://issues.jboss.org/browse/ARQ-2175 > Project: Arquillian > Issue Type: Bug > Components: core > Affects Versions: 1.3.0.Final > Reporter: Matej Novotny > Assignee: Matej Novotny > Fix For: 1.4.0.Final > > > In some rare cases {{DeploymentExceptionHandler}} can pass null value to transformers, which isn't really useful. > This can happen when the exception is {{DeploymentException}} which has no cause (or has itself set as cause). E.g. [this code|https://github.com/arquillian/arquillian-core/blob/1.3.0.Final/container/impl-base/src/main/java/org/jboss/arquillian/container/impl/client/container/DeploymentExceptionHandler.java#L106-L108] can yield {{null}}. > I came across this in combination with [wildfly-arquillian|https://github.com/wildfly/wildfly-arquillian] and certain Arq. interceptor ordering (so that this exception handler was called first and the exception wasn't wrapped yet). -- This message was sent by Atlassian JIRA (v7.5.0#75005)