From issues at jboss.org Tue Mar 13 15:46:00 2018 From: issues at jboss.org (Corey Puffalt (JIRA)) Date: Tue, 13 Mar 2018 15:46:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1321) Support for HTTPS in URLs injected with @ArquillianResource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545404#comment-13545404 ] Corey Puffalt commented on ARQ-1321: ------------------------------------ Is this likely to ever be integrated into Arquillian? > Support for HTTPS in URLs injected with @ArquillianResource > ----------------------------------------------------------- > > Key: ARQ-1321 > URL: https://issues.jboss.org/browse/ARQ-1321 > Project: Arquillian > Issue Type: Feature Request > Reporter: Samuel Santos > Assignee: Samuel Santos > > When injecting an URL like the following: > {code:java} > @ArquillianResource URL url; > {code} > HTTP protocol will always be used. This happens because "http" is hard-coded in {{URLResourceProvider}}. > Vineet Reynolds suggested that we can create the type {{SecureUrl}} and a {{SecureUrlResourceProvider}} to allow us to use HTTPS: > {code:java} > @ArquillianResource SecureUrl url; > {code} > Any comment? -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Mar 19 12:32:00 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Mon, 19 Mar 2018 12:32:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2179) Upgrade to Selenium 3.11.0 In-Reply-To: References: Message-ID: Matous Jobanek created ARQ-2179: ----------------------------------- Summary: Upgrade to Selenium 3.11.0 Key: ARQ-2179 URL: https://issues.jboss.org/browse/ARQ-2179 Project: Arquillian Issue Type: Bug Components: Extension - Drone Affects Versions: drone_2.5.1 Reporter: Matous Jobanek -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Mar 20 05:15:01 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 20 Mar 2018 05:15:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2179) Upgrade to Selenium 3.11.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2179: -------------------------------- Affects Version/s: drone_2.5.0 (was: drone_2.5.1) > Upgrade to Selenium 3.11.0 > -------------------------- > > Key: ARQ-2179 > URL: https://issues.jboss.org/browse/ARQ-2179 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Affects Versions: drone_2.5.0 > Reporter: Matous Jobanek > Fix For: drone_2.5.1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Mar 20 05:15:01 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 20 Mar 2018 05:15:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2179) Upgrade to Selenium 3.11.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek updated ARQ-2179: -------------------------------- Fix Version/s: drone_2.5.1 > Upgrade to Selenium 3.11.0 > -------------------------- > > Key: ARQ-2179 > URL: https://issues.jboss.org/browse/ARQ-2179 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Affects Versions: drone_2.5.0 > Reporter: Matous Jobanek > Fix For: drone_2.5.1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Mar 20 05:15:02 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 20 Mar 2018 05:15:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2179) Upgrade to Selenium 3.11.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek reassigned ARQ-2179: ----------------------------------- Assignee: Matous Jobanek > Upgrade to Selenium 3.11.0 > -------------------------- > > Key: ARQ-2179 > URL: https://issues.jboss.org/browse/ARQ-2179 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Affects Versions: drone_2.5.0 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.5.1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Mar 20 05:15:03 2018 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Tue, 20 Mar 2018 05:15:03 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2179) Upgrade to Selenium 3.11.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matous Jobanek closed ARQ-2179. ------------------------------- Resolution: Done > Upgrade to Selenium 3.11.0 > -------------------------- > > Key: ARQ-2179 > URL: https://issues.jboss.org/browse/ARQ-2179 > Project: Arquillian > Issue Type: Bug > Components: Extension - Drone > Affects Versions: drone_2.5.0 > Reporter: Matous Jobanek > Assignee: Matous Jobanek > Fix For: drone_2.5.1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Mar 23 11:31:02 2018 From: issues at jboss.org (Gordon Hutchison (JIRA)) Date: Fri, 23 Mar 2018 11:31:02 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2153) Enable @Deployment @ShouldThrowException(DefinitionException.class) in WebSphere Liberty Managed Container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550743#comment-13550743 ] Gordon Hutchison commented on ARQ-2153: --------------------------------------- The problem was only surfacing for the Deployment tests. I think the expected approach is that the outer exception is a standard Arquillian one (org.jboss.arquillian.container.spi.client.container.DeploymentException) but that this can wrap a 'cause' exception that is the domain specific one (i.e. in my case the javax.enterprise.inject.spi.DefinitionException or javax.enterprise.inject.spi.DeploymentException). I coded up and tested this approach in https://github.com/arquillian/arquillian-container-was/pull/33. The extension of the PR woudl be to take PR33 and a table of all known Liberty causes for Deployment Exceptions and fully populate the set of 'cause' exceptions that could then be used in ShouldThrows. > Enable @Deployment @ShouldThrowException(DefinitionException.class) in WebSphere Liberty Managed Container > ---------------------------------------------------------------------------------------------------------- > > Key: ARQ-2153 > URL: https://issues.jboss.org/browse/ARQ-2153 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Affects Versions: 1.0.0.Final > Environment: MicroProfile FaultTolerance TCK testing with arquillian-wlp-managed-8.5 container. > For example testing > https://github.com/eclipse/microprofile-fault-tolerance/blob/master/tck/src/main/java/org/eclipse/microprofile/fault/tolerance/tck/invalidParameters/InvalidCircuitBreakerDelayTest.java > with open Liberty or any other Arquillian test testing for DefinitionExceptions that cause > Deployment Exceptions. > Reporter: Gordon Hutchison > Assignee: Gerhard Poul > Priority: Minor > > When running the MicroProfile Fault Tolerance TCK there are numerous tests' > deploy methods that have: > {code:java} > @Deployment > @ShouldThrowException(DefinitionException.class) > public static WebArchive deploy() {... > {code} > The current wlp-managed-8.5 container return these as Deployment > Exceptions to the test client which makes the TCK tests fail even if the server > has raised a definition exception. > I have a code patch from an IBM colleague Nathan Mittlestat (whose permission I have to > make this 'issue' and a pull request from on his behalf ) along the lines of: > {code:java} > private void checkForDefinitionExceptions(String applicationName) > { > String messagesFile = containerConfiguration.getWlpHome() + "/usr/servers/" + containerConfiguration.getServerName() + "/logs/messages.log"; > BufferedReader br = null; > try { > br = new BufferedReader(new InputStreamReader(new FileInputStream(messagesFile))); > String line; > while ((line = br.readLine()) != null) { > if (line.contains("CWWKZ0002E: An exception occurred while starting the application " + applicationName + ".") > && (line.contains("org.jboss.weld.exceptions.DefinitionException") || line.contains("javax.enterprise.inject.spi.DefinitionException"))) { > System.out.println("############DEBUG found CWWKZ0002E for application: " + applicationName); > System.out.println(line); > throw new DefinitionException(line); > } > } > } catch (IOException e) { > System.err.println("Exception while reading messages.log" + e.toString()); > e.printStackTrace(); > // } catch (FileNotFoundException e) { > // System.err.println("Exception while reading messages.log" + e.toString()); > // e.printStackTrace(); > } finally { > try { > if (br != null) > br.close(); > } catch (Exception e) { > System.err.println("Exception while closing bufferedreader " + e.toString()); > e.printStackTrace(); > } > } > } > {code} > This method is called in waitForApplicationTargetState if a wrapping Deployment exception > is observed: > > {code:java} > } catch (Exception e) { > checkForDefinitionExceptions(applicationName); > throw new DeploymentException("Exception while checking application state.", e); > } > {code} > I will do a PR shortly. > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Mar 23 11:50:01 2018 From: issues at jboss.org (Gordon Hutchison (JIRA)) Date: Fri, 23 Mar 2018 11:50:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2180) Copy across undeploy's deleteIfExists+deleteOnExit to !isDeployTypeXml (Dropins deployment) In-Reply-To: References: Message-ID: Gordon Hutchison created ARQ-2180: ------------------------------------- Summary: Copy across undeploy's deleteIfExists+deleteOnExit to !isDeployTypeXml (Dropins deployment) Key: ARQ-2180 URL: https://issues.jboss.org/browse/ARQ-2180 Project: Arquillian Issue Type: Bug Components: WebSphere Containers Affects Versions: 1.4.0.Final Environment: Websphere Liberty FAT test buckets such as https://github.com/OpenLiberty/open-liberty/tree/integration/dev/com.ibm.ws.microprofile.faulttolerance_fat_tck Reporter: Gordon Hutchison Assignee: Gerhard Poul Priority: Minor We sometimes see a timing issue with undeploy which looks like it has already been addressed if isDeployTypeXml==true but most of our tests use the dropin deploy method. I mirrored the code over with: public void undeploy(final Archive archive) throws DeploymentException { if (log.isLoggable(Level.FINER)) { log.entering(className, "undeploy"); } String archiveName = archive.getName(); String deployName = createDeploymentName(archiveName); String deployDir = null; // IBM expedient patch for FAT test problems this was just done to prevent it // having to be added to each arquillian.xml it would not be part of the PR containerConfiguration.setFailSafeUndeployment(true); try { // If deploy type is xml, then remove the application from the xml file, which // causes undeploy if (containerConfiguration.isDeployTypeXML()) { // Read the server.xml file into Memory Document document = readServerXML(); // Remove the archive from the server.xml file removeApplication(document, deployName); removeActivationSpecJmsQueueJmsTopic(document); // Update server.xml on file system writeServerXML(document); // Wait until the application is undeployed waitForApplicationTargetState(deployName, false, this.containerConfiguration.getAppUndeployTimeout()); } // Now we can proceed and delete the archive for either deploy type if (containerConfiguration.isDeployTypeXML()) { deployDir = getAppDirectory(); } else { deployDir = getDropInDirectory(); } // Remove the deployed archive File exportedArchiveLocation = new File(deployDir, archiveName); if (!containerConfiguration.isFailSafeUndeployment()) { try { if (!Files.deleteIfExists(exportedArchiveLocation.toPath())) { throw new DeploymentException("Archive already deleted from deployment directory"); } } catch (IOException e) { throw new DeploymentException("Unable to delete archive from deployment directory", e); } } else { try { Files.deleteIfExists(exportedArchiveLocation.toPath()); } catch (IOException e) { log.log(Level.WARNING, "Unable to delete archive from deployment directory -> failsafe -> file marked for delete on exit", e); exportedArchiveLocation.deleteOnExit(); } } // If it was the archive deletion that caused the undeploy we wait for the // correct state if (!containerConfiguration.isDeployTypeXML()) { // Wait until the application is undeployed waitForApplicationTargetState(deployName, false, this.containerConfiguration.getAppUndeployTimeout()); } } catch (Exception e) { throw new DeploymentException("Exception while undeploying application.", e); } if (log.isLoggable(Level.FINER)) { log.exiting(className, "undeploy"); } } I will now do a PR with the above (minus the containerConfiguration.setFailSafeUndeployment(true); line.) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Mar 23 13:05:00 2018 From: issues at jboss.org (Gordon Hutchison (JIRA)) Date: Fri, 23 Mar 2018 13:05:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2180) Copy across undeploy's deleteIfExists+deleteOnExit to !isDeployTypeXml (Dropins deployment) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550837#comment-13550837 ] Gordon Hutchison commented on ARQ-2180: --------------------------------------- Have done https://github.com/arquillian/arquillian-container-was/pull/35/files just doing some further regression tests. > Copy across undeploy's deleteIfExists+deleteOnExit to !isDeployTypeXml (Dropins deployment) > ------------------------------------------------------------------------------------------- > > Key: ARQ-2180 > URL: https://issues.jboss.org/browse/ARQ-2180 > Project: Arquillian > Issue Type: Bug > Components: WebSphere Containers > Affects Versions: 1.4.0.Final > Environment: Websphere Liberty FAT test buckets such as https://github.com/OpenLiberty/open-liberty/tree/integration/dev/com.ibm.ws.microprofile.faulttolerance_fat_tck > Reporter: Gordon Hutchison > Assignee: Gerhard Poul > Priority: Minor > > We sometimes see a timing issue with undeploy which looks like it has already been addressed if isDeployTypeXml==true but most of our tests use the dropin deploy method. I mirrored the code over with: > public void undeploy(final Archive archive) throws DeploymentException { > if (log.isLoggable(Level.FINER)) { > log.entering(className, "undeploy"); > } > String archiveName = archive.getName(); > String deployName = createDeploymentName(archiveName); > String deployDir = null; > // IBM expedient patch for FAT test problems this was just done to prevent it > // having to be added to each arquillian.xml it would not be part of the PR > containerConfiguration.setFailSafeUndeployment(true); > try { > // If deploy type is xml, then remove the application from the xml file, which > // causes undeploy > if (containerConfiguration.isDeployTypeXML()) { > // Read the server.xml file into Memory > Document document = readServerXML(); > // Remove the archive from the server.xml file > removeApplication(document, deployName); > removeActivationSpecJmsQueueJmsTopic(document); > // Update server.xml on file system > writeServerXML(document); > // Wait until the application is undeployed > waitForApplicationTargetState(deployName, false, this.containerConfiguration.getAppUndeployTimeout()); > } > // Now we can proceed and delete the archive for either deploy type > if (containerConfiguration.isDeployTypeXML()) { > deployDir = getAppDirectory(); > } else { > deployDir = getDropInDirectory(); > } > // Remove the deployed archive > File exportedArchiveLocation = new File(deployDir, archiveName); > if (!containerConfiguration.isFailSafeUndeployment()) { > try { > if (!Files.deleteIfExists(exportedArchiveLocation.toPath())) { > throw new DeploymentException("Archive already deleted from deployment directory"); > } > } catch (IOException e) { > throw new DeploymentException("Unable to delete archive from deployment directory", e); > } > } else { > try { > Files.deleteIfExists(exportedArchiveLocation.toPath()); > } catch (IOException e) { > log.log(Level.WARNING, > "Unable to delete archive from deployment directory -> failsafe -> file marked for delete on exit", > e); > exportedArchiveLocation.deleteOnExit(); > } > } > // If it was the archive deletion that caused the undeploy we wait for the > // correct state > if (!containerConfiguration.isDeployTypeXML()) { > // Wait until the application is undeployed > waitForApplicationTargetState(deployName, false, this.containerConfiguration.getAppUndeployTimeout()); > } > } catch (Exception e) { > throw new DeploymentException("Exception while undeploying application.", e); > } > if (log.isLoggable(Level.FINER)) { > log.exiting(className, "undeploy"); > } > } > I will now do a PR with the above (minus the containerConfiguration.setFailSafeUndeployment(true); > line.) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Mar 26 10:07:01 2018 From: issues at jboss.org (=?UTF-8?Q?Jos=C3=A9_Rosa_=28JIRA=29?=) Date: Mon, 26 Mar 2018 10:07:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1967) Support 'alternative' deploy of ASM in Jacoco In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551451#comment-13551451 ] Jos? Rosa commented on ARQ-1967: -------------------------------- Hi, This is quite old, but still I was unable to find any examples on how to use this parameter with Maven. Can you provide one? Thanks [~aslak] > Support 'alternative' deploy of ASM in Jacoco > ---------------------------------------------- > > Key: ARQ-1967 > URL: https://issues.jboss.org/browse/ARQ-1967 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Jacoco > Affects Versions: jacoco_1.0.0.Alpha8 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: jacoco_1.0.0.Alpha9 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Mar 26 10:07:01 2018 From: issues at jboss.org (=?UTF-8?Q?Jos=C3=A9_Rosa_=28JIRA=29?=) Date: Mon, 26 Mar 2018 10:07:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1967) Support 'alternative' deploy of ASM in Jacoco In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551451#comment-13551451 ] Jos? Rosa edited comment on ARQ-1967 at 3/26/18 10:06 AM: ---------------------------------------------------------- Hi, This is quite old, but still I was unable to find any examples on how to use this parameter with Maven. Can you please provide such an example? Thank you in advance [~aslak] was (Author: joserosapt): Hi, This is quite old, but still I was unable to find any examples on how to use this parameter with Maven. Can you provide one? Thanks [~aslak] > Support 'alternative' deploy of ASM in Jacoco > ---------------------------------------------- > > Key: ARQ-1967 > URL: https://issues.jboss.org/browse/ARQ-1967 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Jacoco > Affects Versions: jacoco_1.0.0.Alpha8 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: jacoco_1.0.0.Alpha9 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Mar 27 15:46:00 2018 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Tue, 27 Mar 2018 15:46:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2180) Copy across undeploy's deleteIfExists+deleteOnExit to !isDeployTypeXml (Dropins deployment) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARQ-2180 started by Gerhard Poul. ----------------------------------------- > Copy across undeploy's deleteIfExists+deleteOnExit to !isDeployTypeXml (Dropins deployment) > ------------------------------------------------------------------------------------------- > > Key: ARQ-2180 > URL: https://issues.jboss.org/browse/ARQ-2180 > Project: Arquillian > Issue Type: Bug > Components: WebSphere Containers > Affects Versions: 1.4.0.Final > Environment: Websphere Liberty FAT test buckets such as https://github.com/OpenLiberty/open-liberty/tree/integration/dev/com.ibm.ws.microprofile.faulttolerance_fat_tck > Reporter: Gordon Hutchison > Assignee: Gerhard Poul > Priority: Minor > > We sometimes see a timing issue with undeploy which looks like it has already been addressed if isDeployTypeXml==true but most of our tests use the dropin deploy method. I mirrored the code over with: > public void undeploy(final Archive archive) throws DeploymentException { > if (log.isLoggable(Level.FINER)) { > log.entering(className, "undeploy"); > } > String archiveName = archive.getName(); > String deployName = createDeploymentName(archiveName); > String deployDir = null; > // IBM expedient patch for FAT test problems this was just done to prevent it > // having to be added to each arquillian.xml it would not be part of the PR > containerConfiguration.setFailSafeUndeployment(true); > try { > // If deploy type is xml, then remove the application from the xml file, which > // causes undeploy > if (containerConfiguration.isDeployTypeXML()) { > // Read the server.xml file into Memory > Document document = readServerXML(); > // Remove the archive from the server.xml file > removeApplication(document, deployName); > removeActivationSpecJmsQueueJmsTopic(document); > // Update server.xml on file system > writeServerXML(document); > // Wait until the application is undeployed > waitForApplicationTargetState(deployName, false, this.containerConfiguration.getAppUndeployTimeout()); > } > // Now we can proceed and delete the archive for either deploy type > if (containerConfiguration.isDeployTypeXML()) { > deployDir = getAppDirectory(); > } else { > deployDir = getDropInDirectory(); > } > // Remove the deployed archive > File exportedArchiveLocation = new File(deployDir, archiveName); > if (!containerConfiguration.isFailSafeUndeployment()) { > try { > if (!Files.deleteIfExists(exportedArchiveLocation.toPath())) { > throw new DeploymentException("Archive already deleted from deployment directory"); > } > } catch (IOException e) { > throw new DeploymentException("Unable to delete archive from deployment directory", e); > } > } else { > try { > Files.deleteIfExists(exportedArchiveLocation.toPath()); > } catch (IOException e) { > log.log(Level.WARNING, > "Unable to delete archive from deployment directory -> failsafe -> file marked for delete on exit", > e); > exportedArchiveLocation.deleteOnExit(); > } > } > // If it was the archive deletion that caused the undeploy we wait for the > // correct state > if (!containerConfiguration.isDeployTypeXML()) { > // Wait until the application is undeployed > waitForApplicationTargetState(deployName, false, this.containerConfiguration.getAppUndeployTimeout()); > } > } catch (Exception e) { > throw new DeploymentException("Exception while undeploying application.", e); > } > if (log.isLoggable(Level.FINER)) { > log.exiting(className, "undeploy"); > } > } > I will now do a PR with the above (minus the containerConfiguration.setFailSafeUndeployment(true); > line.) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Mar 28 09:59:01 2018 From: issues at jboss.org (=?UTF-8?Q?Jos=C3=A9_Rosa_=28JIRA=29?=) Date: Wed, 28 Mar 2018 09:59:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1967) Support 'alternative' deploy of ASM in Jacoco In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13552898#comment-13552898 ] Jos? Rosa commented on ARQ-1967: -------------------------------- An example on how to configure the extension can be found in the release notes: [Arquillian Extension Jacoco 1.0.0.Alpha9 Released|http://arquillian.org/blog/2017/01/09/arquillian-extension-jacoco-1-0-0-Alpha9/index.html] > Support 'alternative' deploy of ASM in Jacoco > ---------------------------------------------- > > Key: ARQ-1967 > URL: https://issues.jboss.org/browse/ARQ-1967 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Jacoco > Affects Versions: jacoco_1.0.0.Alpha8 > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: jacoco_1.0.0.Alpha9 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Mar 29 16:03:01 2018 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Thu, 29 Mar 2018 16:03:01 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2153) Enable @Deployment @ShouldThrowException(DefinitionException.class) in WebSphere Liberty Managed Container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Poul updated ARQ-2153: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: was_1.0.0.next Resolution: Done > Enable @Deployment @ShouldThrowException(DefinitionException.class) in WebSphere Liberty Managed Container > ---------------------------------------------------------------------------------------------------------- > > Key: ARQ-2153 > URL: https://issues.jboss.org/browse/ARQ-2153 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Affects Versions: 1.0.0.Final > Environment: MicroProfile FaultTolerance TCK testing with arquillian-wlp-managed-8.5 container. > For example testing > https://github.com/eclipse/microprofile-fault-tolerance/blob/master/tck/src/main/java/org/eclipse/microprofile/fault/tolerance/tck/invalidParameters/InvalidCircuitBreakerDelayTest.java > with open Liberty or any other Arquillian test testing for DefinitionExceptions that cause > Deployment Exceptions. > Reporter: Gordon Hutchison > Assignee: Gerhard Poul > Priority: Minor > Fix For: was_1.0.0.next > > > When running the MicroProfile Fault Tolerance TCK there are numerous tests' > deploy methods that have: > {code:java} > @Deployment > @ShouldThrowException(DefinitionException.class) > public static WebArchive deploy() {... > {code} > The current wlp-managed-8.5 container return these as Deployment > Exceptions to the test client which makes the TCK tests fail even if the server > has raised a definition exception. > I have a code patch from an IBM colleague Nathan Mittlestat (whose permission I have to > make this 'issue' and a pull request from on his behalf ) along the lines of: > {code:java} > private void checkForDefinitionExceptions(String applicationName) > { > String messagesFile = containerConfiguration.getWlpHome() + "/usr/servers/" + containerConfiguration.getServerName() + "/logs/messages.log"; > BufferedReader br = null; > try { > br = new BufferedReader(new InputStreamReader(new FileInputStream(messagesFile))); > String line; > while ((line = br.readLine()) != null) { > if (line.contains("CWWKZ0002E: An exception occurred while starting the application " + applicationName + ".") > && (line.contains("org.jboss.weld.exceptions.DefinitionException") || line.contains("javax.enterprise.inject.spi.DefinitionException"))) { > System.out.println("############DEBUG found CWWKZ0002E for application: " + applicationName); > System.out.println(line); > throw new DefinitionException(line); > } > } > } catch (IOException e) { > System.err.println("Exception while reading messages.log" + e.toString()); > e.printStackTrace(); > // } catch (FileNotFoundException e) { > // System.err.println("Exception while reading messages.log" + e.toString()); > // e.printStackTrace(); > } finally { > try { > if (br != null) > br.close(); > } catch (Exception e) { > System.err.println("Exception while closing bufferedreader " + e.toString()); > e.printStackTrace(); > } > } > } > {code} > This method is called in waitForApplicationTargetState if a wrapping Deployment exception > is observed: > > {code:java} > } catch (Exception e) { > checkForDefinitionExceptions(applicationName); > throw new DeploymentException("Exception while checking application state.", e); > } > {code} > I will do a PR shortly. > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Mar 29 16:04:00 2018 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Thu, 29 Mar 2018 16:04:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2180) Copy across undeploy's deleteIfExists+deleteOnExit to !isDeployTypeXml (Dropins deployment) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Poul updated ARQ-2180: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/arquillian/arquillian-container-was/pull/35 > Copy across undeploy's deleteIfExists+deleteOnExit to !isDeployTypeXml (Dropins deployment) > ------------------------------------------------------------------------------------------- > > Key: ARQ-2180 > URL: https://issues.jboss.org/browse/ARQ-2180 > Project: Arquillian > Issue Type: Bug > Components: WebSphere Containers > Affects Versions: 1.4.0.Final > Environment: Websphere Liberty FAT test buckets such as https://github.com/OpenLiberty/open-liberty/tree/integration/dev/com.ibm.ws.microprofile.faulttolerance_fat_tck > Reporter: Gordon Hutchison > Assignee: Gerhard Poul > Priority: Minor > Fix For: was_1.0.0.next > > > We sometimes see a timing issue with undeploy which looks like it has already been addressed if isDeployTypeXml==true but most of our tests use the dropin deploy method. I mirrored the code over with: > public void undeploy(final Archive archive) throws DeploymentException { > if (log.isLoggable(Level.FINER)) { > log.entering(className, "undeploy"); > } > String archiveName = archive.getName(); > String deployName = createDeploymentName(archiveName); > String deployDir = null; > // IBM expedient patch for FAT test problems this was just done to prevent it > // having to be added to each arquillian.xml it would not be part of the PR > containerConfiguration.setFailSafeUndeployment(true); > try { > // If deploy type is xml, then remove the application from the xml file, which > // causes undeploy > if (containerConfiguration.isDeployTypeXML()) { > // Read the server.xml file into Memory > Document document = readServerXML(); > // Remove the archive from the server.xml file > removeApplication(document, deployName); > removeActivationSpecJmsQueueJmsTopic(document); > // Update server.xml on file system > writeServerXML(document); > // Wait until the application is undeployed > waitForApplicationTargetState(deployName, false, this.containerConfiguration.getAppUndeployTimeout()); > } > // Now we can proceed and delete the archive for either deploy type > if (containerConfiguration.isDeployTypeXML()) { > deployDir = getAppDirectory(); > } else { > deployDir = getDropInDirectory(); > } > // Remove the deployed archive > File exportedArchiveLocation = new File(deployDir, archiveName); > if (!containerConfiguration.isFailSafeUndeployment()) { > try { > if (!Files.deleteIfExists(exportedArchiveLocation.toPath())) { > throw new DeploymentException("Archive already deleted from deployment directory"); > } > } catch (IOException e) { > throw new DeploymentException("Unable to delete archive from deployment directory", e); > } > } else { > try { > Files.deleteIfExists(exportedArchiveLocation.toPath()); > } catch (IOException e) { > log.log(Level.WARNING, > "Unable to delete archive from deployment directory -> failsafe -> file marked for delete on exit", > e); > exportedArchiveLocation.deleteOnExit(); > } > } > // If it was the archive deletion that caused the undeploy we wait for the > // correct state > if (!containerConfiguration.isDeployTypeXML()) { > // Wait until the application is undeployed > waitForApplicationTargetState(deployName, false, this.containerConfiguration.getAppUndeployTimeout()); > } > } catch (Exception e) { > throw new DeploymentException("Exception while undeploying application.", e); > } > if (log.isLoggable(Level.FINER)) { > log.exiting(className, "undeploy"); > } > } > I will now do a PR with the above (minus the containerConfiguration.setFailSafeUndeployment(true); > line.) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Mar 29 16:04:00 2018 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Thu, 29 Mar 2018 16:04:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2180) Copy across undeploy's deleteIfExists+deleteOnExit to !isDeployTypeXml (Dropins deployment) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Poul updated ARQ-2180: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: was_1.0.0.next Resolution: Done > Copy across undeploy's deleteIfExists+deleteOnExit to !isDeployTypeXml (Dropins deployment) > ------------------------------------------------------------------------------------------- > > Key: ARQ-2180 > URL: https://issues.jboss.org/browse/ARQ-2180 > Project: Arquillian > Issue Type: Bug > Components: WebSphere Containers > Affects Versions: 1.4.0.Final > Environment: Websphere Liberty FAT test buckets such as https://github.com/OpenLiberty/open-liberty/tree/integration/dev/com.ibm.ws.microprofile.faulttolerance_fat_tck > Reporter: Gordon Hutchison > Assignee: Gerhard Poul > Priority: Minor > Fix For: was_1.0.0.next > > > We sometimes see a timing issue with undeploy which looks like it has already been addressed if isDeployTypeXml==true but most of our tests use the dropin deploy method. I mirrored the code over with: > public void undeploy(final Archive archive) throws DeploymentException { > if (log.isLoggable(Level.FINER)) { > log.entering(className, "undeploy"); > } > String archiveName = archive.getName(); > String deployName = createDeploymentName(archiveName); > String deployDir = null; > // IBM expedient patch for FAT test problems this was just done to prevent it > // having to be added to each arquillian.xml it would not be part of the PR > containerConfiguration.setFailSafeUndeployment(true); > try { > // If deploy type is xml, then remove the application from the xml file, which > // causes undeploy > if (containerConfiguration.isDeployTypeXML()) { > // Read the server.xml file into Memory > Document document = readServerXML(); > // Remove the archive from the server.xml file > removeApplication(document, deployName); > removeActivationSpecJmsQueueJmsTopic(document); > // Update server.xml on file system > writeServerXML(document); > // Wait until the application is undeployed > waitForApplicationTargetState(deployName, false, this.containerConfiguration.getAppUndeployTimeout()); > } > // Now we can proceed and delete the archive for either deploy type > if (containerConfiguration.isDeployTypeXML()) { > deployDir = getAppDirectory(); > } else { > deployDir = getDropInDirectory(); > } > // Remove the deployed archive > File exportedArchiveLocation = new File(deployDir, archiveName); > if (!containerConfiguration.isFailSafeUndeployment()) { > try { > if (!Files.deleteIfExists(exportedArchiveLocation.toPath())) { > throw new DeploymentException("Archive already deleted from deployment directory"); > } > } catch (IOException e) { > throw new DeploymentException("Unable to delete archive from deployment directory", e); > } > } else { > try { > Files.deleteIfExists(exportedArchiveLocation.toPath()); > } catch (IOException e) { > log.log(Level.WARNING, > "Unable to delete archive from deployment directory -> failsafe -> file marked for delete on exit", > e); > exportedArchiveLocation.deleteOnExit(); > } > } > // If it was the archive deletion that caused the undeploy we wait for the > // correct state > if (!containerConfiguration.isDeployTypeXML()) { > // Wait until the application is undeployed > waitForApplicationTargetState(deployName, false, this.containerConfiguration.getAppUndeployTimeout()); > } > } catch (Exception e) { > throw new DeploymentException("Exception while undeploying application.", e); > } > if (log.isLoggable(Level.FINER)) { > log.exiting(className, "undeploy"); > } > } > I will now do a PR with the above (minus the containerConfiguration.setFailSafeUndeployment(true); > line.) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Mar 29 16:05:00 2018 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Thu, 29 Mar 2018 16:05:00 -0400 (EDT) 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 ] Gerhard Poul resolved ARQ-2162. ------------------------------- Fix Version/s: was_1.0.0.next Resolution: Done > 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 > Fix For: was_1.0.0.next > > > 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 Thu Mar 29 16:07:00 2018 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Thu, 29 Mar 2018 16:07:00 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-2130) Unaccessible arquillian-was-remote-8.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Poul closed ARQ-2130. ----------------------------- Resolution: Partially Completed > Unaccessible arquillian-was-remote-8.5 > -------------------------------------- > > Key: ARQ-2130 > URL: https://issues.jboss.org/browse/ARQ-2130 > Project: Arquillian > Issue Type: Enhancement > Components: WebSphere Containers > Affects Versions: was_1.0.0.Beta2 > Reporter: Vlastislav Ramik > Assignee: Gerhard Poul > Priority: Critical > > I'm not able to get > {noformat} > org.jboss.arquillian.container > arquillian-was-remote-8.5 > 1.0.0.Beta2 > {noformat} > It seems that the module is not released: https://github.com/arquillian/arquillian-container-was/blob/master/pom.xml#L79-L88 -- This message was sent by Atlassian JIRA (v7.5.0#75005)