March 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13200) Upgrade Smallrye Opentracing to 1.3.4

by Ingo Weiss (Jira)

[ https://issues.redhat.com/browse/WFLY-13200?page=com.atlassian.jira.plugi... ] Ingo Weiss reassigned WFLY-13200: --------------------------------- Assignee: Daniel Kreling (was: Emmanuel Hugonnet) > Upgrade Smallrye Opentracing to 1.3.4 > -------------------------------------- > > Key: WFLY-13200 > URL: https://issues.redhat.com/browse/WFLY-13200 > Project: WildFly > Issue Type: Component Upgrade > Components: MP OpenTracing > Affects Versions: 7.3.0.GA > Reporter: Ingo Weiss > Assignee: Daniel Kreling > Priority: Major > Labels: MP3.3 > Fix For: 7.3.1.GA > > > Upgrade smallrye opentracing to 1.3.4 to have dependencies versions in sync with MP 3.3 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4484) Support SSH authentication for Git persistence

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4484?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4484: -------------------------------- Fix Version/s: 11.0.0.CR1 (was: 11.0.0.Beta10) > Support SSH authentication for Git persistence > ---------------------------------------------- > > Key: WFCORE-4484 > URL: https://issues.redhat.com/browse/WFCORE-4484 > Project: WildFly Core > Issue Type: Feature Request > Components: Management, Security > Reporter: Farah Juma > Assignee: Ashley Abdel-Sayed > Priority: Major > Labels: EAP-CD19 > Fix For: 11.0.0.CR1 > > > Currently Elytron only supports authentication for HTTP(s) URLS so there is no way to connect to a SSH git server to pull/push configuration history -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4670) Upgrade JBoss MSC to 1.4.12.Final

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4670?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4670: -------------------------------- Fix Version/s: 11.0.0.CR1 (was: 11.0.0.Beta10) > Upgrade JBoss MSC to 1.4.12.Final > --------------------------------- > > Key: WFCORE-4670 > URL: https://issues.redhat.com/browse/WFCORE-4670 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Server > Reporter: Katarina Hermanova > Assignee: Richard Opalka > Priority: Major > Fix For: 11.0.0.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5127) DMNBuildBusinessKnowledgeModelBenchmark fails after resource refactor

by Daniel Rosa (Jira)

[ https://issues.redhat.com/browse/DROOLS-5127?page=com.atlassian.jira.plug... ] Daniel Rosa updated DROOLS-5127: -------------------------------- Tester: Daniel Rosa > DMNBuildBusinessKnowledgeModelBenchmark fails after resource refactor > --------------------------------------------------------------------- > > Key: DROOLS-5127 > URL: https://issues.redhat.com/browse/DROOLS-5127 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2451) FD_ALL3: improvements over FD_ALL

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2451?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2451: --------------------------- Description: Improvements to {{FD_ALL}}. * Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be *default*, and as such, deprecated/removed). * When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat It is crucial that setting the timestamp in the map is quick, especially since this is done on every message. This should not be an issue, as we fetch the current time from the time service, which does *not* call {{System.nanoTime()}} or {{System.currentTimeMillis()}} every time. The advantage is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P. We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0. However, this is only feasible with sending a message N-1 times (e.g. TCP); for UDP we don't have such an 'anycast' available. was: Improvements to {{FD_ALL}}. * Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be *default*, and as such, deprecated/removed). * When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat It is crucial that setting the in the map is quick, especially since this is done on every message. This should not be an issue, as we fetch the current time from the time service, which does *not* call {{System.nanoTime()}} or {{System.currentTimeMillis()}} every time. The advantage is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P. We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0. However, this is only feasible with sending a message N-1 times (e.g. TCP); for UDP we don't have such an 'anycast' available. > FD_ALL3: improvements over FD_ALL > --------------------------------- > > Key: JGRP-2451 > URL: https://issues.redhat.com/browse/JGRP-2451 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.0, 4.2.1 > > > Improvements to {{FD_ALL}}. > * Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be *default*, and as such, deprecated/removed). > * When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat > It is crucial that setting the timestamp in the map is quick, especially since this is done on every message. This should not be an issue, as we fetch the current time from the time service, which does *not* call {{System.nanoTime()}} or {{System.currentTimeMillis()}} every time. > The advantage is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P. > We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0. > However, this is only feasible with sending a message N-1 times (e.g. TCP); for UDP we don't have such an 'anycast' available. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5126) JavaDialectConfiguration.LANGUAGE_LEVELS being strings causes binary search to not properly locate version 9

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5126?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-5126. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/dde2f16d1a01a5c84983a9913576e02... > JavaDialectConfiguration.LANGUAGE_LEVELS being strings causes binary search to not properly locate version 9 > ------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-5126 > URL: https://issues.redhat.com/browse/DROOLS-5126 > Project: Drools > Issue Type: Bug > Affects Versions: 7.33.0.Final > Reporter: Nikola Atanasov > Assignee: Mario Fusco > Priority: Minor > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > When i created a simple drools project (version 7.33.0.final) in eclipse (plugin version 7.32.0 final), i ran into the following error. > (Note: drools file didn't specify "dialect java") > {code:java} > java.lang.RuntimeException: Unable to load dialect 'org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration:java:org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration' > at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.addDialect(KnowledgeBuilderConfigurationImpl.java:405) > at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.buildDialectConfigurationMap(KnowledgeBuilderConfigurationImpl.java:391) > at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.init(KnowledgeBuilderConfigurationImpl.java:239) > at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.init(KnowledgeBuilderConfigurationImpl.java:191) > at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.<init>(KnowledgeBuilderConfigurationImpl.java:159) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.getBuilderConfiguration(AbstractKieProject.java:302) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.createKnowledgeBuilder(AbstractKieProject.java:288) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages(AbstractKieProject.java:213) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:75) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:274) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:242) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:192) > at com.sample.RunnableTest.createKieBase(RunnableTest.java:67) > at com.sample.RunnableTest.run(RunnableTest.java:36) > at java.base/java.lang.Thread.run(Thread.java:844) > Caused by: java.lang.RuntimeException: value '9' is not a valid language level > at org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration.setJavaLanguageLevel(JavaDialectConfiguration.java:102) > at org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration.init(JavaDialectConfiguration.java:80) > at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.addDialect(KnowledgeBuilderConfigurationImpl.java:401) > ... 14 more > {code} > Once debugged, i saw that the "LANGUAGE_LEVEL" array in "JavaDialectConfiguration" stores the java versions as strings, and in the method that throws the exception "setJavaLanguageLevel", it uses binary search to locate the version from that array. > The problem with this is that it compares them lexicographically, so java version 9 would be greater than versions 10, 11 and 12. > So, out of the array {"1.5", "1.6", "1.7", "1.8", "9", "10", "11", "12"}, to find 9, the following values are tried out: > # Start: low=0, high=7 > # Middle (index 3) is 1.8, smaller than 9, move middle to 10, low=4(mid + 1), high=7 > # Middle (index 5) is 10, smaller than 9, move middle to 11, low=6(mid + 1), high=7 > # Middle (index 6) is 11, smaller than 9, move middle to 12, low=7(mid + 1), high=7 > # Middle is 12, smaller than 9, low > high, end search > The fix would be simple enough, either they should be sorted (lexicographically), or they should be floats. > My default workspace jre is 9.0.1. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5126) JavaDialectConfiguration.LANGUAGE_LEVELS being strings causes binary search to not properly locate version 9

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5126?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-5126: -------------------------------- Sprint: 2020 Week 10-12 (from Mar 2) > JavaDialectConfiguration.LANGUAGE_LEVELS being strings causes binary search to not properly locate version 9 > ------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-5126 > URL: https://issues.redhat.com/browse/DROOLS-5126 > Project: Drools > Issue Type: Bug > Affects Versions: 7.33.0.Final > Reporter: Nikola Atanasov > Assignee: Mario Fusco > Priority: Minor > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > When i created a simple drools project (version 7.33.0.final) in eclipse (plugin version 7.32.0 final), i ran into the following error. > (Note: drools file didn't specify "dialect java") > {code:java} > java.lang.RuntimeException: Unable to load dialect 'org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration:java:org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration' > at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.addDialect(KnowledgeBuilderConfigurationImpl.java:405) > at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.buildDialectConfigurationMap(KnowledgeBuilderConfigurationImpl.java:391) > at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.init(KnowledgeBuilderConfigurationImpl.java:239) > at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.init(KnowledgeBuilderConfigurationImpl.java:191) > at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.<init>(KnowledgeBuilderConfigurationImpl.java:159) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.getBuilderConfiguration(AbstractKieProject.java:302) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.createKnowledgeBuilder(AbstractKieProject.java:288) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages(AbstractKieProject.java:213) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:75) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:274) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:242) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:192) > at com.sample.RunnableTest.createKieBase(RunnableTest.java:67) > at com.sample.RunnableTest.run(RunnableTest.java:36) > at java.base/java.lang.Thread.run(Thread.java:844) > Caused by: java.lang.RuntimeException: value '9' is not a valid language level > at org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration.setJavaLanguageLevel(JavaDialectConfiguration.java:102) > at org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration.init(JavaDialectConfiguration.java:80) > at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.addDialect(KnowledgeBuilderConfigurationImpl.java:401) > ... 14 more > {code} > Once debugged, i saw that the "LANGUAGE_LEVEL" array in "JavaDialectConfiguration" stores the java versions as strings, and in the method that throws the exception "setJavaLanguageLevel", it uses binary search to locate the version from that array. > The problem with this is that it compares them lexicographically, so java version 9 would be greater than versions 10, 11 and 12. > So, out of the array {"1.5", "1.6", "1.7", "1.8", "9", "10", "11", "12"}, to find 9, the following values are tried out: > # Start: low=0, high=7 > # Middle (index 3) is 1.8, smaller than 9, move middle to 10, low=4(mid + 1), high=7 > # Middle (index 5) is 10, smaller than 9, move middle to 11, low=6(mid + 1), high=7 > # Middle (index 6) is 11, smaller than 9, move middle to 12, low=7(mid + 1), high=7 > # Middle is 12, smaller than 9, low > high, end search > The fix would be simple enough, either they should be sorted (lexicographically), or they should be floats. > My default workspace jre is 9.0.1. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13199) Upgrade MicroProfile Health 2.2

by Ingo Weiss (Jira)

[ https://issues.redhat.com/browse/WFLY-13199?page=com.atlassian.jira.plugi... ] Ingo Weiss reassigned WFLY-13199: --------------------------------- Assignee: Daniel Kreling (was: Jeff Mesnil) > Upgrade MicroProfile Health 2.2 > ------------------------------- > > Key: WFLY-13199 > URL: https://issues.redhat.com/browse/WFLY-13199 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Health > Affects Versions: 7.3.0.GA > Reporter: Ingo Weiss > Assignee: Daniel Kreling > Priority: Major > Fix For: 7.3.1.GA > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13199) Upgrade MicroProfile Health 2.2

by Ingo Weiss (Jira)

Ingo Weiss created WFLY-13199: --------------------------------- Summary: Upgrade MicroProfile Health 2.2 Key: WFLY-13199 URL: https://issues.redhat.com/browse/WFLY-13199 Project: WildFly Issue Type: Component Upgrade Components: MP Health Reporter: Ingo Weiss Assignee: Jeff Mesnil Fix For: 19.0.0.Beta3, 20.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5127) DMNBuildBusinessKnowledgeModelBenchmark fails after resource refactor

by Mario Fusco (Jira)

Mario Fusco created DROOLS-5127: ----------------------------------- Summary: DMNBuildBusinessKnowledgeModelBenchmark fails after resource refactor Key: DROOLS-5127 URL: https://issues.redhat.com/browse/DROOLS-5127 Project: Drools Issue Type: Bug Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 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 March 2020