August 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-365) Update B18 to Openshift 3.10

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-365?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-365: ------------------------------------------ Attachment: openshift-3.10-b18.png > Update B18 to Openshift 3.10 > ---------------------------- > > Key: SWSQE-365 > URL: https://issues.jboss.org/browse/SWSQE-365 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > Attachments: openshift-3.10-b18.png > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-369) Update B24 to Openshift 3.10

by Guilherme Baufaker Rêgo (JIRA)

Guilherme Baufaker Rêgo created SWSQE-369: --------------------------------------------- Summary: Update B24 to Openshift 3.10 Key: SWSQE-369 URL: https://issues.jboss.org/browse/SWSQE-369 Project: Kiali QE Issue Type: Sub-task Reporter: Guilherme Baufaker Rêgo Assignee: Michael Foley -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-369) Update B24 to Openshift 3.10

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-369?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo reassigned SWSQE-369: --------------------------------------------- Assignee: Guilherme Baufaker Rêgo (was: Michael Foley) > Update B24 to Openshift 3.10 > ---------------------------- > > Key: SWSQE-369 > URL: https://issues.jboss.org/browse/SWSQE-369 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-366) Update B12 to Openshift 3.10

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-366?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo reassigned SWSQE-366: --------------------------------------------- Assignee: Guilherme Baufaker Rêgo (was: Michael Foley) > Update B12 to Openshift 3.10 > ---------------------------- > > Key: SWSQE-366 > URL: https://issues.jboss.org/browse/SWSQE-366 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3875) [jdk10] PatchModuleInvalidationWithRenamingFailureTestCase#test failure

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3875?page=com.atlassian.jira.plugi... ] James Perkins resolved WFCORE-3875. ----------------------------------- Resolution: Done > [jdk10] PatchModuleInvalidationWithRenamingFailureTestCase#test failure > ----------------------------------------------------------------------- > > Key: WFCORE-3875 > URL: https://issues.jboss.org/browse/WFCORE-3875 > Project: WildFly Core > Issue Type: Bug > Components: Patching , Test Suite > Affects Versions: 5.0.0.Beta4 > Reporter: Petr Kremensky > Assignee: Richard Opalka > Labels: Java10, Java11 > Fix For: 6.0.0.Alpha6 > > > org.jboss.as.patching.tests.PatchModuleInvalidationWithRenamingFailureTestCase#test from patching module of wildfly-core fails with JDK10, works fine with JDK9. > > *reproduce* > {noformat} > wildfly-core]$ mvn test -Dtest=PatchModuleInvalidationWithRenamingFailureTestCase#test -pl patching > ... > [INFO] Running org.jboss.as.patching.tests.PatchModuleInvalidationWithRenamingFailureTestCase > [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.363 s <<< FAILURE! - in org.jboss.as.patching.tests.PatchModuleInvalidationWithRenamingFailureTestCase > [ERROR] test(org.jboss.as.patching.tests.PatchModuleInvalidationWithRenamingFailureTestCase) Time elapsed: 0.359 s <<< FAILURE! > java.lang.AssertionError: > Expected: is <false> > but: was <true> > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) > at org.junit.Assert.assertThat(Assert.java:956) > at org.junit.Assert.assertThat(Assert.java:923) > at org.jboss.as.patching.tests.PatchModuleInvalidationWithRenamingFailureTestCase.test(PatchModuleInvalidationWithRenamingFailureTestCase.java:97) > ... > {noformat} > > Environment: > {noformat} > Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00) > Maven home: /usr/lib/maven > Java version: 10.0.1, vendor: Oracle Corporation > {noformat} > Byteman is being involved in the test. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3874) [jdk10] FileSystemDeploymentServiceUnitTestCase#testNoUndeployment failure

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3874?page=com.atlassian.jira.plugi... ] James Perkins resolved WFCORE-3874. ----------------------------------- Resolution: Done > [jdk10] FileSystemDeploymentServiceUnitTestCase#testNoUndeployment failure > -------------------------------------------------------------------------- > > Key: WFCORE-3874 > URL: https://issues.jboss.org/browse/WFCORE-3874 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner, Test Suite > Affects Versions: 5.0.0.Beta4 > Reporter: Petr Kremensky > Assignee: Richard Opalka > Labels: Java10, Java11 > Fix For: 6.0.0.Alpha6 > > > org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase#testNoUndeployment from deployment-scanner module of wildfly-core fails with JDK10, works fine with JDK9. > *reproduce* > {noformat} > wildfly-core]$ mvn test -Dtest=FileSystemDeploymentServiceUnitTestCase#testNoUndeployment -pl deployment-scanner > ... > [INFO] Running org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase > [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.121 s <<< FAILURE! - in org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase > [ERROR] testNoUndeployment(org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase) Time elapsed: 0.115 s <<< FAILURE! > java.lang.AssertionError: RuntimeException expected > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase.testNoUndeployment(FileSystemDeploymentServiceUnitTestCase.java:1798) > ... > {noformat} > Environment: > {noformat} > Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00) > Maven home: /usr/lib/maven > Java version: 10.0.1, vendor: Oracle Corporation > {noformat} > Byteman is being involved in the test. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3869) [jdk10] DeletionCollisionTest#testFileLockByRemoveContent failure

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3869?page=com.atlassian.jira.plugi... ] James Perkins resolved WFCORE-3869. ----------------------------------- Resolution: Done > [jdk10] DeletionCollisionTest#testFileLockByRemoveContent failure > ----------------------------------------------------------------- > > Key: WFCORE-3869 > URL: https://issues.jboss.org/browse/WFCORE-3869 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner, Test Suite > Affects Versions: 5.0.0.Beta4 > Reporter: Petr Kremensky > Assignee: Richard Opalka > Labels: Java10, Java11 > Fix For: 6.0.0.Alpha6 > > > org.jboss.as.repository.DeletionCollisionTest#testFileLockByRemoveContent from deployment-repository module of wildfly-core fails with JDK10, works fine with JDK9. > > *reproduce* > {noformat} > wildfly-core]$ mvn test -Dtest=DeletionCollisionTest#testFileLockByRemoveContent -pl deployment-repository > ... > [INFO] Running org.jboss.as.repository.DeletionCollisionTest > [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.307 s <<< FAILURE! - in org.jboss.as.repository.DeletionCollisionTest > [ERROR] testFileLockByRemoveContent(org.jboss.as.repository.DeletionCollisionTest) Time elapsed: 0.301 s <<< FAILURE! > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at org.jboss.as.repository.DeletionCollisionTest.testFileLockByRemoveContent(DeletionCollisionTest.java:117) > ... > {noformat} > > Exception expected by the test - [WFLYDR0019|https://github.com/wildfly/wildfly-core/blob/master/deployment...] > {noformat} > Caused by: org.jboss.as.repository.ExplodedContentException: WFLYDR0019: Deployment is locked by another operation > at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:550) > at org.jboss.as.repository.DeletionCollisionTest.lambda$testFileLockByRemoveContent$3(DeletionCollisionTest.java:111) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > {noformat} > > Actual exception thrown with JDK10 > {noformat} > Caused by: org.jboss.as.repository.ExplodedContentException: WFLYDR0020: Error accessing deployment files > at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:563) > at org.jboss.as.repository.DeletionCollisionTest.lambda$testFileLockByRemoveContent$3(DeletionCollisionTest.java:111) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > at java.base/java.lang.Thread.run(Thread.java:844) > Caused by: java.io.FileNotFoundException: target > at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:376) > at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374) > at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374) > at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374) > at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374) > at org.jboss.as.repository.PathUtil.getFile(PathUtil.java:374) > at org.jboss.as.repository.PathUtil.readFile(PathUtil.java:356) > at org.jboss.as.repository.ContentRepositoryImpl.readContent(ContentRepositoryImpl.java:554) > ... 5 more > {noformat} > Environment: > {noformat} > Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00) > Maven home: /usr/lib/maven > Java version: 10.0.1, vendor: Oracle Corporation > {noformat} > Byteman is being involved in the test. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3992) InstallationManagerService should not allow duplicate module paths

by James Perkins (JIRA)

James Perkins created WFCORE-3992: ------------------------------------- Summary: InstallationManagerService should not allow duplicate module paths Key: WFCORE-3992 URL: https://issues.jboss.org/browse/WFCORE-3992 Project: WildFly Core Issue Type: Bug Components: Patching Reporter: James Perkins Assignee: James Perkins The {{InstallationManagerService}} uses a {{List}} for the which allows for duplicate files to be used for the {{module.path}} resulting in the following exception: {code} MSC000001: Failed to start service jboss.patching.manager: org.jboss.msc.service.StartException in service jboss.patching.manager: java.lang.IllegalStateException: Duplicate layer 'base' at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:106) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736) at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698) at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.IllegalStateException: Duplicate layer 'base' at org.jboss.as.patching.installation.LayersFactory$ProcessedLayers.addLayer(LayersFactory.java:305) at org.jboss.as.patching.installation.LayersFactory.processRoot(LayersFactory.java:182) at org.jboss.as.patching.installation.LayersFactory.process(LayersFactory.java:127) at org.jboss.as.patching.installation.LayersFactory.load(LayersFactory.java:86) at org.jboss.as.patching.installation.InstallationManagerImpl.<init>(InstallationManagerImpl.java:47) at org.jboss.as.patching.installation.InstallationManager.load(InstallationManager.java:185) at org.jboss.as.patching.installation.InstallationManagerService.load(InstallationManagerService.java:128) at org.jboss.as.patching.installation.InstallationManagerService.start(InstallationManagerService.java:63) ... 8 more {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-82) MP Health endpoint forces authentication ATM, spec violation

by Rostislav Svoboda (JIRA)

Rostislav Svoboda created WFWIP-82: -------------------------------------- Summary: MP Health endpoint forces authentication ATM, spec violation Key: WFWIP-82 URL: https://issues.jboss.org/browse/WFWIP-82 Project: WildFly WIP Issue Type: Bug Components: MP Health Reporter: Rostislav Svoboda Assignee: Jeff Mesnil Priority: Blocker MP Health endpoint forces authentication ATM, this is spec violation. {code} Security Aspects regarding the secure access of health check information. • A producer MAY support security on all health check invocations (i.e. authentication) • A producer MUST not enforce security by default, it SHOULD be an opt-in feature (i.e. configuration change) {code} Already discussed with Jeff, for tracing purposes mainly. We can use this for discussion about implementation (and model changes) of opt-in feature to enable authentication. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-81) MP Health reports UP when there is port collision for port 8080

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFWIP-81?page=com.atlassian.jira.plugin.s... ] Rostislav Svoboda updated WFWIP-81: ----------------------------------- Component/s: MP Health > MP Health reports UP when there is port collision for port 8080 > --------------------------------------------------------------- > > Key: WFWIP-81 > URL: https://issues.jboss.org/browse/WFWIP-81 > Project: WildFly WIP > Issue Type: Bug > Components: MP Health > Reporter: Rostislav Svoboda > Assignee: Kabir Khan > Priority: Critical > > MP Health reports UP when there is port collision for port 8080. > I have simple python app to acquire port 8080 and once it runs I start WF server > {code} > import SimpleHTTPServer > import SocketServer > PORT = 8080 > Handler = SimpleHTTPServer.SimpleHTTPRequestHandler > httpd = SocketServer.TCPServer(("127.0.0.1", PORT), Handler) > print "serving at port", PORT > httpd.serve_forever() > {code} > WF reports Address already in use /127.0.0.1:8080, deployments are not deployed. > Accessing http://localhost:9990/health/ reports "outcome":"UP" > I think this is wrong and DOWN should be reported. > Spec is misleading because it says {{A producer without health check procedures installed MUST returns positive overall outcome (i.e. HTTP 200)}} but it silently assumes server started correctly. > I believe authors of the spec expected that if there is some trouble like port collision the server doesn't start, WildFly is a bit further as it allows to boot even if some services are not started properly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2018