[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
[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
[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
[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
[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
[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