December 2020 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (DROOLS-5859) Include new impl (kie-pmml-trusty) in product artifacts

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5859?page=com.atlassian.jira.plug... ] Gabriele Cardosi reassigned DROOLS-5859: ---------------------------------------- Assignee: Gabriele Cardosi (was: Mario Fusco) > Include new impl (kie-pmml-trusty) in product artifacts > ------------------------------------------------------- > > Key: DROOLS-5859 > URL: https://issues.redhat.com/browse/DROOLS-5859 > Project: Drools > Issue Type: Feature Request > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Include PMML trusty inside Business Central (kie-wb-distributions/business-central-parent/) and Kie-Server (droolsjbpm-integration/kie-server-parent/) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5867) Update ApplyPmmlModelCommand to manage both PMML implementations

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5867?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-5867: ------------------------------------- Description: Currently, ApplyPmmlModelCommand (inside drools) invoke directly the legacy PMML delegate (ApplyPmmlModelCommandExecutorImpl). # move Command newApplyPmmlModel(PMMLRequestData request); from ExtendedKieCommands to KieCommands # define PMMLCommandExecutor interface inside kie-internal (droolsjbpm-knowledge) # define PMMLCommandExecutorFactory interface inside kie-internal (droolsjbpm-knowledge) # write PMMLCommandExecutor implementation (inside kie-pmml-trusty ) # write PMMLCommandExecutorFactory implementation (inside kie-pmml-trusty ) # write kie.konf in the same module as PMMLCommandExecutorFactory implementation to bind the implementation to the interface # create a static method "isToEnable()" to be used by PMMLAssemblerService(s) and ApplyPmmlModelCommand to retrieve which implementation is to be enabled - it will replace the ones in PMMLAssemblerService(s) (inside kie-api) # modify ApplyPmmlModelCommand to switch between factories/implementations (using the above method to choose the implementation to enable) was: Currently, ApplyPmmlModelCommand (inside drools) invoke directly the legacy PMML delegate (ApplyPmmlModelCommandExecutorImpl). # define PMMLCommandExecutor interface inside kie-internal (droolsjbpm-knowledge) # write a PMMLCommandExecutor factory (where ? It must be visible by drools-core inside ApplyPmmlModelCommand) # write a PMMLCommandExecutor implementation (where ? It must be visible by PMMLCommandExecutor factory ) # modify ApplyPmmlModelCommand to switch between factories/implementations. > Update ApplyPmmlModelCommand to manage both PMML implementations > ----------------------------------------------------------------- > > Key: DROOLS-5867 > URL: https://issues.redhat.com/browse/DROOLS-5867 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Currently, ApplyPmmlModelCommand (inside drools) invoke directly the legacy PMML delegate (ApplyPmmlModelCommandExecutorImpl). > # move Command newApplyPmmlModel(PMMLRequestData request); from ExtendedKieCommands to KieCommands > # define PMMLCommandExecutor interface inside kie-internal (droolsjbpm-knowledge) > # define PMMLCommandExecutorFactory interface inside kie-internal (droolsjbpm-knowledge) > # write PMMLCommandExecutor implementation (inside kie-pmml-trusty ) > # write PMMLCommandExecutorFactory implementation (inside kie-pmml-trusty ) > # write kie.konf in the same module as PMMLCommandExecutorFactory implementation to bind the implementation to the interface > # create a static method "isToEnable()" to be used by PMMLAssemblerService(s) and ApplyPmmlModelCommand to retrieve which implementation is to be enabled - it will replace the ones in PMMLAssemblerService(s) (inside kie-api) > # modify ApplyPmmlModelCommand to switch between factories/implementations (using the above method to choose the implementation to enable) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5812) DMN demonstrate use of Listener to trace DT Annotation

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5812?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5812: ----------------------------------- Sprint: 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30) (was: 2020 Week 46-48 (from Nov 9)) > DMN demonstrate use of Listener to trace DT Annotation > ------------------------------------------------------ > > Key: DROOLS-5812 > URL: https://issues.redhat.com/browse/DROOLS-5812 > Project: Drools > Issue Type: Task > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-4640) DMN Editor constraint on Type does not reflect in Decision Table

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4640?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4640: -------------------------------- Tester: Jozef Marko > DMN Editor constraint on Type does not reflect in Decision Table > ---------------------------------------------------------------- > > Key: DROOLS-4640 > URL: https://issues.redhat.com/browse/DROOLS-4640 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Matteo Mortari > Assignee: Guilherme Gomes > Priority: Major > Attachments: image-2019-10-11-11-02-31-881.png > > > Editing the classic Traffic Violation item definition to put enumeration on string for the violation type "speed", "parking", ... once done in the item definition is not reflected in the decision table, and that prevents also from getting the real intended DT static analysis message for the table. > !image-2019-10-11-11-02-31-881.png|thumbnail! > in the attached screenshot I entered the data also manually in the DT's property right tab. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5865) Folder test-classes is not excluded from kie-maven-plugin build

by Nikolas Falco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5865?page=com.atlassian.jira.plug... ] Nikolas Falco edited comment on DROOLS-5865 at 11/30/20 7:48 AM: ----------------------------------------------------------------- This issue is not related to DROOLS-4440 but requires a similar fix to the [BuildMojo.writeClassFiles|https://github.com/kiegroup/droolsjbpm-integrat... like: {code:java} .filter(name -> name.endsWith(".class") && !name.contains("target/classes") && !name.contains("target\\classes") && !name.contains("target/test-classes") && !name.contains("target\\test-classes") ) {code} or any better manage of resource to copy. The issue happens when you run two maven command like "mvn clean verify && mvn deploy". The second run deploy without a clean causes the issue where the jar contains unexpected test classes under unexpected path was (Author: nfalco79): This issue is not related to DROOLS-4440 but requires a similar fix to the [BuildMojo.writeClassFiles|https://github.com/kiegroup/droolsjbpm-integrat... like: {code:java} .filter(name -> name.endsWith(".class") && !name.contains("target/classes") && !name.contains("target\\classes") && !name.contains("target/test-classes") && !name.contains("target\\test-classes") ) {code} or any better manage of resource to copy. > Folder test-classes is not excluded from kie-maven-plugin build > --------------------------------------------------------------- > > Key: DROOLS-5865 > URL: https://issues.redhat.com/browse/DROOLS-5865 > Project: Drools > Issue Type: Bug > Components: tools > Affects Versions: 7.46.0.Final > Reporter: Laura Cameran > Assignee: Mario Fusco > Priority: Major > > Maven goal kie-maven-plugin:build doesn't exclude folder "target/test-classes". As result, if we previously run for example mvn test goal, the target/test-classes folder is included during the write operation on outputDirectory. > > I think this issue is related to DROOLS-4440. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14151) Introduce a base "health" subsystem and move microprofile-health to the microprofile feature-pack

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-14151?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFLY-14151: ------------------------------- Summary: Introduce a base "health" subsystem and move microprofile-health to the microprofile feature-pack (was: Introduce a base "metrics" subsystem and move microprofile-health to the microprofile feature-pack) > Introduce a base "health" subsystem and move microprofile-health to the microprofile feature-pack > ------------------------------------------------------------------------------------------------- > > Key: WFLY-14151 > URL: https://issues.redhat.com/browse/WFLY-14151 > Project: WildFly > Issue Type: Feature Request > Components: MP Metrics > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Major > Fix For: 22.0.0.Beta1 > > > The microprofile-metrics-smallrye subsystem is provided by the wilfdfly galleon-pack. > However its logical inclusion is in the microprofile feature pack (org.wildfly:wildfly-mp-feature-pack-galleon-common) which provides features for MicroProfile. > We should move the subsystem (and extension) to this feature pack. > However, the base WildFly server is still expected to provide "base" metrics (for the WildFly management model and the JVM) that can be consumed out of the box. > I propose to introduce a simple "metrics" subsystem (without any external dependencies) that exposes the WildFly management model and the JVM (using JMX) to the /metrics endpoint (on the management port) with the Prometheus format. > The microprofile-metrics-smallrye subsystem will be refactored to "plug" in the same HTTP endpoint and overrides the base metrics endpoint and provide the full features of MicroProfile metrics (application metrics, JSON output, etc.) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14145) Temporarily ignore SecurityCommandsTestCase

by Farah Juma (Jira)

Farah Juma created WFLY-14145: --------------------------------- Summary: Temporarily ignore SecurityCommandsTestCase Key: WFLY-14145 URL: https://issues.redhat.com/browse/WFLY-14145 Project: WildFly Issue Type: Task Components: Test Suite Reporter: Farah Juma Assignee: Farah Juma WFCORE-5095 introduces new default TLS resources in the Elytron subsystem configuration. This causes tests in the WildFly {{org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase}} to fail since these tests make assertions related to the number of TLS resources in the Elytron subsystem. WFLY-13782 updates this test accordingly. However, to allow CI to pass with only the changes for WFCORE-5095, we're going to need to first ignore {{SecurityCommandTestCase}} in WildFly, then merge WFCORE-5095, then un-ignore the test as part of WFLY-13782 and merge that one. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14152) Upgrade smallrye-fault-tolerance to 4.3.2

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-14152?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-14152: ---------------------------------- Affects Version/s: 22.0.0.Alpha1 (was: 21.0.0.Final) > Upgrade smallrye-fault-tolerance to 4.3.2 > ----------------------------------------- > > Key: WFLY-14152 > URL: https://issues.redhat.com/browse/WFLY-14152 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Fault Tolerance > Affects Versions: 22.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 22.0.0.Alpha1 > > > Release notes: > https://github.com/smallrye/smallrye-fault-tolerance/releases/tag/4.3.2 > Changes: > https://github.com/smallrye/smallrye-fault-tolerance/compare/4.3.1...4.3.2 > No notable changes. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5724) Fix DMN-PMML integration

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5724?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5724: ----------------------------------- Sprint: 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30) (was: 2020 Week 46-48 (from Nov 9)) > Fix DMN-PMML integration > ------------------------ > > Key: DROOLS-5724 > URL: https://issues.redhat.com/browse/DROOLS-5724 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Matteo Mortari > Priority: Critical > Labels: TrustyAI > > To have Trusty-PMML working withouth MVEL (i.e. drools-7.45) a fix has been made. > Unfortunately, that modification broke DMN-PMML integration inside drools. > -A very quick and dirty solution has been to- > -1) expose the- > -DMNRuntimeKB runtimeKB inside DMNRuntimeImpl- > -2) based on the actual class at runtime, if it is "DMNRuntimeKBWrappingIKB" use a code patch the works in drools, otherwise the "kogito" one.- > -This has been done only for extreme needs, but must be redisigned and properly implemented ASAP- > The root cause of that is DMN ignoring the Kogito API. > Kogito defines a _container_ class (org.kie.kogito.app.Application) that is meant to be used by all components (processes, ruleunits, decisions and predictions) to invoke the others. > Trusty PMML fullfill this API, exposing predictive models throught the the > {code:java} > org.kie.kogito.app.PredictionModels.getPredictionModel(String modelName) > {code} > but since DMNKogito completely ignore this, a painful workaround has been needed to solve the issue. > Instead of adding workarounds one on top of the other, a different approach on DMN side is required, respecting the constraints put by the containers. > Having done that, the DMN-PMML integration would be automatically resolved. > I'll be available for more explanation, if needed. > [~evacchi] [~danielezonca] [~tirelli] FYI -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14139) Upgrade messaging schema version to 13.0

by Tomas Hofman (Jira)

Tomas Hofman created WFLY-14139: ----------------------------------- Summary: Upgrade messaging schema version to 13.0 Key: WFLY-14139 URL: https://issues.redhat.com/browse/WFLY-14139 Project: WildFly Issue Type: Task Components: JMS Affects Versions: 21.0.0.Beta1 Reporter: Tomas Hofman Assignee: Emmanuel Hugonnet Upgrade messaging schema to 12.0 -- This message was sent by Atlassian Jira (v7.13.8#713008)

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