September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5624) It should be possible to escape the build popup

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-5624?page=com.atlassian.jira.plug... ] Toni Rikkola updated DROOLS-5624: --------------------------------- Sprint: 2020 Week 37-39 (from Sep 7) (was: 2020 Week 37-39 (from Sep 7), 2020 Week 40-42 (from Sep 28)) > It should be possible to escape the build popup > ----------------------------------------------- > > Key: DROOLS-5624 > URL: https://issues.redhat.com/browse/DROOLS-5624 > Project: Drools > Issue Type: Feature Request > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > > The build can take 1, 5 or 60 minutes. UI should not block you from using the workbench during this time. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5624) It should be possible to escape the build popup

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-5624?page=com.atlassian.jira.plug... ] Toni Rikkola closed DROOLS-5624. -------------------------------- Resolution: Out of Date > It should be possible to escape the build popup > ----------------------------------------------- > > Key: DROOLS-5624 > URL: https://issues.redhat.com/browse/DROOLS-5624 > Project: Drools > Issue Type: Feature Request > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > > The build can take 1, 5 or 60 minutes. UI should not block you from using the workbench during this time. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4070) Improve service discovery/wiring to allow defining the order of alternative services

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4070?page=com.atlassian.jira.plug... ] Gabriele Cardosi commented on DROOLS-4070: ------------------------------------------ Hi [~mfusco], which kind of services should be covered by this ticket ? Global ones (e.g. ResourceFactoryServiceImpl, ServiceRegistryImpl) or even resource-specific ones ? In the latter case, may I be kept in the loop, since PMML is the only case where that happen ? Thk! :) > Improve service discovery/wiring to allow defining the order of alternative services > ------------------------------------------------------------------------------------ > > Key: DROOLS-4070 > URL: https://issues.redhat.com/browse/DROOLS-4070 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Critical > > At the moment if you have 2 or more different implementations of a service on the classpath, the service discovery/wiring mechanism randomly chooses one of them (the one that comes first in the classpath). It is required to provide a way to explicitly configure a priority among these services. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5143) Bouncycastle - Failing tests in RESTEasy TS

by Emmanuel Hugonnet (Jira)

[ https://issues.redhat.com/browse/WFCORE-5143?page=com.atlassian.jira.plug... ] Emmanuel Hugonnet updated WFCORE-5143: -------------------------------------- Component/s: Security > Bouncycastle - Failing tests in RESTEasy TS > ------------------------------------------- > > Key: WFCORE-5143 > URL: https://issues.redhat.com/browse/WFCORE-5143 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 13.0.0.Beta6 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Blocker > > [~ehugonnet] please set the component. I cannot find anything suitable. > I noticed it in the context of a bootable JAR execution but [~jfdenise] confirmed this happens with WF 21 Beta1. > This is about some tests in the RESTEasy TS which has been adapted to execute against bootable JARs through a specific profile [1]. > The tests are running successfully with WildFly 20.0.1.Final (the {{ejb}} layer needs to be removed for this experiment to be run [2]) but fail against 21.0.0.Beta1, so it is a regression. > There are 108 tests failing but this JIRA is reporting just one as a reference, see "Steps to reproduce" in order to have a full list: > {code} > org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest.org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest > Error Details > Cannot deploy BlacklistedMediaTypeTest.war: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.module.service.\"deployment.BlacklistedMediaTypeTest.war\".main" => "WFLYSRV0179: Failed to load module: deployment.BlacklistedMediaTypeTest.war > Caused by: org.jboss.modules.ModuleNotFoundException: org.bouncycastle"}}}} > {code} > *Steps to reproduce*: > 1. clone https://github.com/fabiobrz/Resteasy/tree/bootable-jar-support > 2. build RESTEasy: > {code} > $ mvn install -Dmaven.test.skip=true -Dmaven.repo.local=/home/my-local-repo > {code} > 3. cd to testsuite directory: > {code} > cd testsuite > {code} > 4. run the test against WF 21.0.0.Beta1 with bootable JAR: > {code} > mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=21.0.0.Beta1 -Dtest=org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable > {code} > The test should *fail* > 5. run the test against WF 20.0.1.Final with bootable JAR: > {code} > mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=20.0.1.Final -Dtest=org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable > {code} > The test should *pass* > [1] > https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46... > [2] > https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2502) If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace

by Sebastian Laskawiec (Jira)

[ https://issues.redhat.com/browse/JGRP-2502?page=com.atlassian.jira.plugin... ] Sebastian Laskawiec commented on JGRP-2502: ------------------------------------------- [~filippe.spolti] If you're asking specifically about Keycloak, than you can specify {{docker run --network host -it quay.io/keycloak/keycloak:latest -c standalone.xml}}. > If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace > ------------------------------------------------------------------------------------ > > Key: JGRP-2502 > URL: https://issues.redhat.com/browse/JGRP-2502 > Project: JGroups > Issue Type: Bug > Affects Versions: 5.0.4 > Reporter: Filippe Spolti > Assignee: Sebastian Laskawiec > Priority: Minor > > If no namespace is set it defaults to the "default" ocp namespace which will case the warn as described in the log message below: > > {code:java} > WARN [org.jgroups.protocols.kubernetes.KUBE_PING] (thread-9,ee,hdm78-kieserver-1-nggcf) failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1, headers={Authorization=#MASKED:937#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@69991c01] for cluster [ee], namespace [default], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/namespaces/default/pods]] > {code} > IMHO the default namespace should not be used in this case since this namespace should not be used to deploy applications. > > If the namespace is not set it means that we do not want to enable the clustering feature, as the namespace is set if the namespace is not set, this condition [1] is not satisfied and the configuration will proceed. > > Another problem found in the tests is that, if we do set the KUBERNETES_NAMESPACE with no value, it will detect that the env has an value and will try to use a blank namespace: > > {code:java} > failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1 , headers={Authorization=#MASKED:874#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@17978314] for cluster [ee], namespace [], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/pods ]] > {code} > > [1] - https://github.com/jgroups-extras/jgroups-kubernetes/blob/master/src/main/java/org/jgroups/protocols/kubernetes/KUBE_PING.java#L145 > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5669) DMN Decision Table Analysis integrated in Maven and Kogito

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5669?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5669: ----------------------------------- Affects: Documentation (Ref Guide, User Guide, etc.) > DMN Decision Table Analysis integrated in Maven and Kogito > ---------------------------------------------------------- > > Key: DROOLS-5669 > URL: https://issues.redhat.com/browse/DROOLS-5669 > Project: Drools > Issue Type: Story > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > *Motivation*: currently DT (static) analysis is only available when editor is open > *Goals*: perform DMN DT analysis during build time, so the user is not required to await when backend services are available, or even worse needed to open DMN files one by one and checking DT analysis manually per each file. > *Impacts*: integration with kie-maven-plugin, Kogito codegen (which in turn is used by Kogito Quarkus extension AND Kogito maven plugin for SB) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5143) Bouncycastle - Failing tests in RESTEasy TS

by Emmanuel Hugonnet (Jira)

[ https://issues.redhat.com/browse/WFCORE-5143?page=com.atlassian.jira.plug... ] Emmanuel Hugonnet moved WFLY-13909 to WFCORE-5143: -------------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-5143 (was: WFLY-13909) Affects Version/s: 13.0.0.Beta6 (was: 21.0.0.Beta1) > Bouncycastle - Failing tests in RESTEasy TS > ------------------------------------------- > > Key: WFCORE-5143 > URL: https://issues.redhat.com/browse/WFCORE-5143 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 13.0.0.Beta6 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Blocker > > [~ehugonnet] please set the component. I cannot find anything suitable. > I noticed it in the context of a bootable JAR execution but [~jfdenise] confirmed this happens with WF 21 Beta1. > This is about some tests in the RESTEasy TS which has been adapted to execute against bootable JARs through a specific profile [1]. > The tests are running successfully with WildFly 20.0.1.Final (the {{ejb}} layer needs to be removed for this experiment to be run [2]) but fail against 21.0.0.Beta1, so it is a regression. > There are 108 tests failing but this JIRA is reporting just one as a reference, see "Steps to reproduce" in order to have a full list: > {code} > org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest.org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest > Error Details > Cannot deploy BlacklistedMediaTypeTest.war: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.module.service.\"deployment.BlacklistedMediaTypeTest.war\".main" => "WFLYSRV0179: Failed to load module: deployment.BlacklistedMediaTypeTest.war > Caused by: org.jboss.modules.ModuleNotFoundException: org.bouncycastle"}}}} > {code} > *Steps to reproduce*: > 1. clone https://github.com/fabiobrz/Resteasy/tree/bootable-jar-support > 2. build RESTEasy: > {code} > $ mvn install -Dmaven.test.skip=true -Dmaven.repo.local=/home/my-local-repo > {code} > 3. cd to testsuite directory: > {code} > cd testsuite > {code} > 4. run the test against WF 21.0.0.Beta1 with bootable JAR: > {code} > mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=21.0.0.Beta1 -Dtest=org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable > {code} > The test should *fail* > 5. run the test against WF 20.0.1.Final with bootable JAR: > {code} > mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=20.0.1.Final -Dtest=org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable > {code} > The test should *pass* > [1] > https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46... > [2] > https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13909) Bouncycastle - Failing tests in RESTEasy TS

by Emmanuel Hugonnet (Jira)

Emmanuel Hugonnet created WFLY-13909: ---------------------------------------- Summary: Bouncycastle - Failing tests in RESTEasy TS Key: WFLY-13909 URL: https://issues.redhat.com/browse/WFLY-13909 Project: WildFly Issue Type: Bug Affects Versions: 21.0.0.Beta1 Reporter: Emmanuel Hugonnet Assignee: Emmanuel Hugonnet [~ehugonnet] please set the component. I cannot find anything suitable. I noticed it in the context of a bootable JAR execution but [~jfdenise] confirmed this happens with WF 21 Beta1. This is about some tests in the RESTEasy TS which has been adapted to execute against bootable JARs through a specific profile [1]. The tests are running successfully with WildFly 20.0.1.Final (the {{ejb}} layer needs to be removed for this experiment to be run [2]) but fail against 21.0.0.Beta1, so it is a regression. There are 108 tests failing but this JIRA is reporting just one as a reference, see "Steps to reproduce" in order to have a full list: {code} org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest.org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest Error Details Cannot deploy BlacklistedMediaTypeTest.war: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.module.service.\"deployment.BlacklistedMediaTypeTest.war\".main" => "WFLYSRV0179: Failed to load module: deployment.BlacklistedMediaTypeTest.war Caused by: org.jboss.modules.ModuleNotFoundException: org.bouncycastle"}}}} {code} *Steps to reproduce*: 1. clone https://github.com/fabiobrz/Resteasy/tree/bootable-jar-support 2. build RESTEasy: {code} $ mvn install -Dmaven.test.skip=true -Dmaven.repo.local=/home/my-local-repo {code} 3. cd to testsuite directory: {code} cd testsuite {code} 4. run the test against WF 21.0.0.Beta1 with bootable JAR: {code} mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=21.0.0.Beta1 -Dtest=org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable {code} The test should *fail* 5. run the test against WF 20.0.1.Final with bootable JAR: {code} mvn clean verify -am -pl integration-tests -Dmaven.repo.local=/home/my-local-repo -Dserver.version=20.0.1.Final -Dtest=org.jboss.resteasy.test.providers.mediatype.BlacklistedMediaTypeTest -Ddisable.microprofile.tests -Dserver.home=foo -Dts.bootable {code} The test should *pass* [1] https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46... [2] https://github.com/resteasy/Resteasy/pull/2526/files#diff-8c7ea03eb619e46... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5647) Add range indexing to AlphaNode

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5647?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5647: ----------------------------------- Sprint: 2020 Week 37-39 (from Sep 7), 2020 Week 40-42 (from Sep 28) (was: 2020 Week 37-39 (from Sep 7)) > Add range indexing to AlphaNode > ------------------------------- > > Key: DROOLS-5647 > URL: https://issues.redhat.com/browse/DROOLS-5647 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.43.1.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Add range indexing to AlphaNode. > FYI) Range indexing for NotNode/ExistsNode : [https://github.com/kiegroup/drools/blob/master/drools-core/src/main/java/...] > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5631) Rule evaluation optimization

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5631?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5631: ----------------------------------- Sprint: 2020 Week 37-39 (from Sep 7), 2020 Week 40-42 (from Sep 28) (was: 2020 Week 37-39 (from Sep 7)) > Rule evaluation optimization > ---------------------------- > > Key: DROOLS-5631 > URL: https://issues.redhat.com/browse/DROOLS-5631 > Project: Drools > Issue Type: Story > Components: core engine > Affects Versions: 7.42.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Motivation: This Story aims at rule evaluation optimization so both Kogito and drools core engine usage will get benefits for overall rule execution. It contains Alpha Node Ordering to maximize sharing and minimize the number of evaluations, Range Indexing (I will file and link later). Other JIRAs may be added later. > Goals: Better rule execution performance. For each improvement, add benchmark and measure the performance gain. > Impact: Better rule execution performance. It might have overhead during rule build time. Will confirm with benchmark anyway. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 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 September 2020