December 2020 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (WFLY-14229) WildFly MP modules should ee.maven.groupId for code base dependencies

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-14229?page=com.atlassian.jira.plugi... ] Yeray Borges Santana updated WFLY-14229: ---------------------------------------- Summary: WildFly MP modules should ee.maven.groupId for code base dependencies (was: WildFly MP metrics and health should use ee.maven.groupId for some dependencies) > WildFly MP modules should ee.maven.groupId for code base dependencies > --------------------------------------------------------------------- > > Key: WFLY-14229 > URL: https://issues.redhat.com/browse/WFLY-14229 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Yeray Borges Santana > Assignee: Yeray Borges Santana > Priority: Minor > > MP spec should be able to be moved to a different Group Id, hence the need of having {{ee.maven.groupId}} for its dependencies which belongs to the base code. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14229) WildFly MP metrics and health should use ee.maven.groupId for some dependencies

by Yeray Borges Santana (Jira)

Yeray Borges Santana created WFLY-14229: ------------------------------------------- Summary: WildFly MP metrics and health should use ee.maven.groupId for some dependencies Key: WFLY-14229 URL: https://issues.redhat.com/browse/WFLY-14229 Project: WildFly Issue Type: Task Components: Build System Reporter: Yeray Borges Santana Assignee: Yeray Borges Santana MP spec should be able to be moved to a different Group Id, hence the need of having {{ee.maven.groupId}} for its dependencies which belongs to the base code. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14199) OnOffOpenTracingTestCase leaves the server in a bad state

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-14199?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-14199: --------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13825 (was: https://github.com/ehsavoie/wildfly/pull/9) > OnOffOpenTracingTestCase leaves the server in a bad state > --------------------------------------------------------- > > Key: WFLY-14199 > URL: https://issues.redhat.com/browse/WFLY-14199 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing, Test Suite > Affects Versions: 22.0.0.Alpha1 > Reporter: Emmanuel Hugonnet > Assignee: James Perkins > Priority: Major > > {color:#333333}OnOffOpenTracingTestCase{color} will leave the server in such a state that SimpleRestClientTestCase will fail. Removing and adding the opentracing subsystem to check that it doesn't work once removed shoudl be reevaluated. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5900) DMN Editor undo CTRL+Z does not work on Win10 but works on VSCode

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5900: -------------------------------------- Summary: DMN Editor undo CTRL+Z does not work on Win10 but works on VSCode Key: DROOLS-5900 URL: https://issues.redhat.com/browse/DROOLS-5900 Project: Drools Issue Type: Bug Components: DMN Editor Reporter: Matteo Mortari Assignee: Guilherme Gomes Attachments: 2020-12-15 16-17-56.mp4 See attached video [^2020-12-15 16-17-56.mp4] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5880) Revisit Kie/Drools maven archetype

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5880?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5880: ----------------------------------- Description: *Motivation*: currently the only 1 available Kie maven archetype for Drools shows sign of age. *Goals*: reconsidering the following aspects: * contains only a mirror test (generated folder/file structure) but doesn't actually "use" the generated project so if it breaks we don't know. Potentially add a maven invoker test in droolsjbpm-integration to check it. * License header: do as Camel / Quarkus do, the end result, the user files, do NOT contain a Red Hat license header. Can be resolved by template engine comment like Camel team did. * the current Drools unit test is not very significative, always check that "type==color" maybe add some Measurement not of type color to get the test more significative * could be worthy to add a {{.gitignore}} since the archetype do not supply one OOTB, especially for the kie-kjar-archetype * currently Stateful Vs CEP test is governed by variable during archetype generation. Experience shows this is overlooked. It is best to actually separate this into 2 separate Archetypes. * currently defines Eclipse IDE exclusion in the generated pom.xml, maybe just easier to: ** always generate it ** bring that into the kie-maven-plugin, albeit it may require providing the xml file manually. Here it could be worthy to check how Quarkus team resolved this issue *Impacts*: archetypes are directly used by end-users when creating a project, but IIRC there is no mention in the Docs (for "v7x series" / Kie) /cc [~lucamolteni][~danielezonca] was: *Motivation*: currently the only 1 available Kie maven archetype for Drools shows sign of age. *Goals*: reconsidering the following aspects: * contains only a mirror test (generated folder/file structure) but doesn't actually "use" the generated project so if it breaks we don't know. Potentially add a maven invoker test in droolsjbpm-integration to check it. * License header: do as Camel / Quarkus do, the end result, the user files, do NOT contain a Red Hat license header. Can be resolved by template engine comment like Camel team did. * the current Drools unit test is not very significative, always check that "type==color" maybe add some Measurement not of type color to get the test more significative * currently Stateful Vs CEP test is governed by variable during archetype generation. Experience shows this is overlooked. It is best to actually separate this into 2 separate Archetypes. * currently defines Eclipse IDE exclusion in the generated pom.xml, maybe just easier to: ** always generate it ** bring that into the kie-maven-plugin, albeit it may require providing the xml file manually. Here it could be worthy to check how Quarkus team resolved this issue *Impacts*: archetypes are directly used by end-users when creating a project, but IIRC there is no mention in the Docs (for "v7x series" / Kie) /cc [~lucamolteni][~danielezonca] > Revisit Kie/Drools maven archetype > ---------------------------------- > > Key: DROOLS-5880 > URL: https://issues.redhat.com/browse/DROOLS-5880 > Project: Drools > Issue Type: Story > Components: integration > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > *Motivation*: currently the only 1 available Kie maven archetype for Drools shows sign of age. > *Goals*: reconsidering the following aspects: > * contains only a mirror test (generated folder/file structure) but doesn't actually "use" the generated project so if it breaks we don't know. Potentially add a maven invoker test in droolsjbpm-integration to check it. > * License header: do as Camel / Quarkus do, the end result, the user files, do NOT contain a Red Hat license header. Can be resolved by template engine comment like Camel team did. > * the current Drools unit test is not very significative, always check that "type==color" maybe add some Measurement not of type color to get the test more significative > * could be worthy to add a {{.gitignore}} since the archetype do not supply one OOTB, especially for the kie-kjar-archetype > * currently Stateful Vs CEP test is governed by variable during archetype generation. Experience shows this is overlooked. It is best to actually separate this into 2 separate Archetypes. > * currently defines Eclipse IDE exclusion in the generated pom.xml, maybe just easier to: > ** always generate it > ** bring that into the kie-maven-plugin, albeit it may require providing the xml file manually. Here it could be worthy to check how Quarkus team resolved this issue > *Impacts*: archetypes are directly used by end-users when creating a project, but IIRC there is no mention in the Docs (for "v7x series" / Kie) > /cc [~lucamolteni][~danielezonca] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2058) Accepted Issuers should not be manually configured in X509RevocationTrustManager

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-2058?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-2058: ---------------------------- Fix Version/s: 1.14.1.CR1 > Accepted Issuers should not be manually configured in X509RevocationTrustManager > -------------------------------------------------------------------------------- > > Key: ELY-2058 > URL: https://issues.redhat.com/browse/ELY-2058 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Sonia Zaldana > Assignee: Sonia Zaldana > Priority: Major > Fix For: 1.14.1.CR1 > > > In the X509RevocationTrustManager.Builder class, we can currently configure the trust manager's accepted issuers. However, the accepted issuers should only be the certificates stored in the trust store. > Allowing users to specify their own accepted issuers could contradict the trust manager's actual accepted issuers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2058) Accepted Issuers should not be manually configured in X509RevocationTrustManager

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-2058?page=com.atlassian.jira.plugin.... ] Farah Juma resolved ELY-2058. ----------------------------- Resolution: Done > Accepted Issuers should not be manually configured in X509RevocationTrustManager > -------------------------------------------------------------------------------- > > Key: ELY-2058 > URL: https://issues.redhat.com/browse/ELY-2058 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Sonia Zaldana > Assignee: Sonia Zaldana > Priority: Major > Fix For: 1.14.1.CR1 > > > In the X509RevocationTrustManager.Builder class, we can currently configure the trust manager's accepted issuers. However, the accepted issuers should only be the certificates stored in the trust store. > Allowing users to specify their own accepted issuers could contradict the trust manager's actual accepted issuers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5899) Expression like BigDecimal_type_property = BigDecimal_type_property.divide(BigDecimal_value) causes a build failure in executable model.

by Luca Molteni (Jira)

[ https://issues.redhat.com/browse/DROOLS-5899?page=com.atlassian.jira.plug... ] Luca Molteni resolved DROOLS-5899. ---------------------------------- Resolution: Fixed https://github.com/kiegroup/drools/commit/8b6d1c54ec9b3e21a1550bb104f7228... > Expression like BigDecimal_type_property = BigDecimal_type_property.divide(BigDecimal_value) causes a build failure in executable model. > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-5899 > URL: https://issues.redhat.com/browse/DROOLS-5899 > Project: Drools > Issue Type: Bug > Components: executable model > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > Labels: support > > Compiling a rule like (*1) which is described in MVEL dialect and uses an expression like _BigDecimal_type_property_ = _BigDecimal_type_property_.divide(_BigDecimal_value_), for example (*1-1), with executable rule models enabled, an error like (*2) occurs. > This issue occurs in the case of using the other basic operation add, subtract and multiply as well as divide. > (*1) > {noformat} > package com.example.reproducer > import com.example.reproducer.Bus > import java.math.BigDecimal > dialect "mvel" > rule "bus3d" > when > $bus : Bus() > then > $bus.weight = $bus.weight.divide(BigDecimal.valueOf(1000)); ..... (*1-1) > System.out.println("***** " + $bus + ", weight = " + $bus.weight); > end > {noformat} > $bus.weight is a BigDecimal type property. > (*2) > {noformat} > [ERROR] Unable to build KieBaseModel:rules > CompilationProblemErrorResult: org.drools.mvelcompiler.MvelCompilerException: RHS doesn't have a type > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14173) MP quickstarts pom.xml is missing asciidoctor-maven-plugin version

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-14173?page=com.atlassian.jira.plugi... ] Eduardo Martins reopened WFLY-14173: ------------------------------------ > MP quickstarts pom.xml is missing asciidoctor-maven-plugin version > ------------------------------------------------------------------ > > Key: WFLY-14173 > URL: https://issues.redhat.com/browse/WFLY-14173 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Affects Versions: 22.0.0.Alpha1 > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Priority: Major > Fix For: 22.0.0.Beta1 > > > We noticed one common warning for all XP2-CR1 MicroProfile Quickstarts that could be simply fixed by introducing the build version for _asciidoctor-maven-plugin_ dependency. > {noformat} > [WARNING] Some problems were encountered while building the effective model for org.jboss.eap.xp.quickstarts:microprofile-config:war:2.0.0.GA > [WARNING] 'build.plugins.plugin.version' for org.asciidoctor:asciidoctor-maven-plugin is missing. @ org.jboss.eap.xp.quickstarts:microprofile-config:[unknown-version], jboss-eap-xp-2.0.0.GA-quickstarts/microprofile-config/pom.xml, line 78, column 15 > [WARNING] > [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[Red Hat JIRA] (ELYWEB-118) Update Elytron Web to build on Fedora 33

by Darran Lofthouse (Jira)

Darran Lofthouse created ELYWEB-118: --------------------------------------- Summary: Update Elytron Web to build on Fedora 33 Key: ELYWEB-118 URL: https://issues.redhat.com/browse/ELYWEB-118 Project: Elytron Web Issue Type: Bug Components: Testsuite Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.8.1.CR1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 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 December 2020