July 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8364) mod_cluster model allows both simple- and dynamic-load-providers to be defined in the model simultaneously

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8364?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-8364: --------------------------------- Affects Version/s: 13.0.0.Final > mod_cluster model allows both simple- and dynamic-load-providers to be defined in the model simultaneously > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-8364 > URL: https://issues.jboss.org/browse/WFLY-8364 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 10.1.0.Final, 13.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > {code} > <subsystem xmlns="urn:jboss:domain:modcluster:3.0"> > <mod-cluster-config advertise-socket="modcluster" connector="ajp"> > <simple-load-provider factor="5"/> > <dynamic-load-provider> > <load-metric type="cpu"/> > </dynamic-load-provider> > </mod-cluster-config> > </subsystem> > {code} > However, it would be ideal if this was reworked into correct resources, like the following: > {{/subsystem=modcluster/proxy=default/load-provider=dynamic}} > {{/subsystem=modcluster/proxy=default/load-provider=simple}} > Jira for that TBD. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3982) Update Capability ServiceTarget/Builder to use the new Service API.

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3982?page=com.atlassian.jira.plugi... ] Jeff Mesnil commented on WFCORE-3982: ------------------------------------- [~ropalka] fiy, this issue will make sure that capabilities work with the new MSC Service API > Update Capability ServiceTarget/Builder to use the new Service API. > ------------------------------------------------------------------- > > Key: WFCORE-3982 > URL: https://issues.jboss.org/browse/WFCORE-3982 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 6.0.0.Alpha4 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > Capabilities provided by service are installed with org.jboss.as.controller.CapabilityServiceTarget#addCapability that uses the deprecated org.jboss.msc.service.Service API. > It is not possible to provide a capability provided by the new org.jboss.msc.Service API. > In particular, there is a chicken and egg issue between org.jboss.as.controller.CapabilityServiceTarget#addCapability that needs an instance of the service(and returns a CapabilityServiceBuilder) and org.jboss.msc.service.ServiceBuilder#provides that creates a Consumer instance to pass to the service instance before this one is set with org.jboss.msc.service.ServiceBuilder#setInstance. > new workflow should be: > {code} > CapabilityServiceBuilder serviceBuilder = context.getCapabilityServiceTarget().addCapability(CAP_NAME); > Consumer<MyValue> consumer = serviceBuilder.provides(CAP_NAME); > Service myService = new MyService(consumer); > serviceBuilder.setInstance(myService) > .install(); > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3982) Update Capability ServiceTarget/Builder to use the new Service API.

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFCORE-3982: ----------------------------------- Summary: Update Capability ServiceTarget/Builder to use the new Service API. Key: WFCORE-3982 URL: https://issues.jboss.org/browse/WFCORE-3982 Project: WildFly Core Issue Type: Bug Components: Management Affects Versions: 6.0.0.Alpha4 Reporter: Jeff Mesnil Assignee: Jeff Mesnil Capabilities provided by service are installed with org.jboss.as.controller.CapabilityServiceTarget#addCapability that uses the deprecated org.jboss.msc.service.Service API. It is not possible to provide a capability provided by the new org.jboss.msc.Service API. In particular, there is a chicken and egg issue between org.jboss.as.controller.CapabilityServiceTarget#addCapability that needs an instance of the service(and returns a CapabilityServiceBuilder) and org.jboss.msc.service.ServiceBuilder#provides that creates a Consumer instance to pass to the service instance before this one is set with org.jboss.msc.service.ServiceBuilder#setInstance. new workflow should be: {code} CapabilityServiceBuilder serviceBuilder = context.getCapabilityServiceTarget().addCapability(CAP_NAME); Consumer<MyValue> consumer = serviceBuilder.provides(CAP_NAME); Service myService = new MyService(consumer); serviceBuilder.setInstance(myService) .install(); {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2810) Kie-dmn OSGI feature can not be installed

by Jiri Petrlik (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2810?page=com.atlassian.jira.plugi... ] Jiri Petrlik commented on DROOLS-2810: -------------------------------------- Problem was caused by changes in drools core dependencies [1]. Fixed by adding model to drools-module feature and OSGIfing module and its dependencies. Unfortunately changes are in three PRs which need to be merged simultaneously. [1] https://github.com/kiegroup/drools/commit/0efe87b4166072eaa9af4076e53471c... > Kie-dmn OSGI feature can not be installed > ----------------------------------------- > > Key: DROOLS-2810 > URL: https://issues.jboss.org/browse/DROOLS-2810 > Project: Drools > Issue Type: Bug > Components: integration > Reporter: Jiri Petrlik > Assignee: Jiri Petrlik > Fix For: 7.10.0.Final > > > It is not possible to install kie-dmn OSGI feature. Installation fails with following exception: > Unable to resolve org.kie.dmn.core/7.10.0.201807310901: missing requirement [org.kie.dmn.core/7.10.0.201807310901] osgi.wiring.package; filter:="(osgi.wiring.package=org.drools.model)" -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-363) Fix failing UI automation tests

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created SWSQE-363: ------------------------------------ Summary: Fix failing UI automation tests Key: SWSQE-363 URL: https://issues.jboss.org/browse/SWSQE-363 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/run-python-ui-te... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 8 months

1
0
0 / 0

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

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3874?page=com.atlassian.jira.plugi... ] Rostislav Svoboda commented on WFCORE-3874: ------------------------------------------- I hit the same issue with Java 11 ea builds. What's the status here ? [~jmesnil] [~ropalka] > [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: ehsavoie Hugonnet > Labels: Java11 > > 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)

5 years, 8 months

1
0
0 / 0

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

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3875?page=com.atlassian.jira.plugi... ] Rostislav Svoboda commented on WFCORE-3875: ------------------------------------------- I hit the same issue with Java 11 ea builds. What's the status here ? [~jmesnil] [~ropalka] > [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: Alexey Loubyansky > Labels: Java11 > > 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)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10091) GC logging is not working on Java 9

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFLY-10091?page=com.atlassian.jira.plugin... ] Rostislav Svoboda updated WFLY-10091: ------------------------------------- Labels: Java11 blocker-WF14 (was: blocker-WF14) > GC logging is not working on Java 9 > ----------------------------------- > > Key: WFLY-10091 > URL: https://issues.jboss.org/browse/WFLY-10091 > Project: WildFly > Issue Type: Bug > Components: Scripts > Reporter: Rostislav Svoboda > Assignee: Radovan Stancel > Priority: Blocker > Labels: Java11, blocker-WF14 > > GC logging is not working on Java 9. This is related to the fact G1 GC is default and there are changes in configuration option. > {code} > GC_LOG="true" ./standalone.sh > {code} > Java 8: > {code} > JAVA_OPTS: -server -verbose:gc -Xloggc:"/Users/rsvoboda/TESTING/7.2.0.CD12.CR1/jboss-eap-7.2/standalone/log/gc.log" > -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 > -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M > -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true > {code} > Java 9: > {code} > JAVA_OPTS: -server -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m > -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10772) WildFly TS failures on Java 11 (--add-modules java.se)

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFLY-10772?page=com.atlassian.jira.plugin... ] Rostislav Svoboda updated WFLY-10772: ------------------------------------- Labels: Java11 (was: ) > WildFly TS failures on Java 11 (--add-modules java.se) > ------------------------------------------------------- > > Key: WFLY-10772 > URL: https://issues.jboss.org/browse/WFLY-10772 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Rostislav Svoboda > Assignee: Rostislav Svoboda > Labels: Java11 > > WildFly TS failures on Java 11 > Majority of fails coul go away by adding {{--add-modules java.se}} into {{modular.jdk.args}} in jdk9 module -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 8 months

1
0
0 / 0

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

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3869?page=com.atlassian.jira.plugi... ] Rostislav Svoboda updated WFCORE-3869: -------------------------------------- Labels: Java11 (was: ) > [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: ehsavoie Hugonnet > Labels: Java11 > > 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)

5 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2018