[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)
3 years, 3 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)
3 years, 3 months
[Red Hat JIRA] (WFCORE-4291) Restore legacy (not "graceful") startup mode
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4291?page=com.atlassian.jira.plug... ]
Jeff Mesnil reassigned WFCORE-4291:
-----------------------------------
Assignee: Jason Lee (was: Jeff Mesnil)
> Restore legacy (not "graceful") startup mode
> --------------------------------------------
>
> Key: WFCORE-4291
> URL: https://issues.redhat.com/browse/WFCORE-4291
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management
> Reporter: Vladimir Grabarchuk
> Assignee: Jason Lee
> Priority: Major
>
> Please allow a configurable legacy startup mode which was the default before WF11, when components can service HTTP requests as soon as they are deployed, not when the container deploys all components.
> The use case for this is the following: there is a configuration service component upon which other components depend for configuration data, requested and served via a HTTP request. With the new "graceful startup" this scenario no longer seems possible, as it results in read timeouts, mis-configured artifacts, and failed deployments altogether.
> If generally feasible, another value of the *--start-mode=legacy* seems appropriate to accommodate the original (legacy) behavior.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 3 months