[JBoss JIRA] (DROOLS-4589) Refactor of Scorecards
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4589?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-4589:
-------------------------------------
Description:
-Re-design and refactoring of Scorecard model in kie-pmml module. The result of which should be...
* Scorecard models uses a standardized "pipeline" for processing requests to apply a model to input data
* Scorecard models use the "re-usable alpha network" approach when possible, minimizing the use of KieSessions and rete.
* Scorecard models use a minimal amount of rules when applying the model to input data, and any generated rules should be in executable model form/format
* Scorecard models are applied via a service interface-
was:
Re-design and refactoring of Scorecard model in kie-pmml module. The result of which should be...
* Scorecard models uses a standardized "pipeline" for processing requests to apply a model to input data
* Scorecard models use the "re-usable alpha network" approach when possible, minimizing the use of KieSessions and rete.
* Scorecard models use a minimal amount of rules when applying the model to input data, and any generated rules should be in executable model form/format
* Scorecard models are applied via a service interface
> Refactor of Scorecards
> ----------------------
>
> Key: DROOLS-4589
> URL: https://issues.redhat.com/browse/DROOLS-4589
> Project: Drools
> Issue Type: Task
> Components: PMML
> Reporter: Lance Leverich
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: CustomerFocusTeam, TrustyAI
>
> -Re-design and refactoring of Scorecard model in kie-pmml module. The result of which should be...
> * Scorecard models uses a standardized "pipeline" for processing requests to apply a model to input data
> * Scorecard models use the "re-usable alpha network" approach when possible, minimizing the use of KieSessions and rete.
> * Scorecard models use a minimal amount of rules when applying the model to input data, and any generated rules should be in executable model form/format
> * Scorecard models are applied via a service interface-
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (DROOLS-4589) Refactor of Scorecards
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-4589?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-4589:
-------------------------------------
Description:
--Re-design and refactoring of Scorecard model in kie-pmml module. The result of which should be...
* Scorecard models uses a standardized "pipeline" for processing requests to apply a model to input data
* Scorecard models use the "re-usable alpha network" approach when possible, minimizing the use of KieSessions and rete.
* Scorecard models use a minimal amount of rules when applying the model to input data, and any generated rules should be in executable model form/format
* Scorecard models are applied via a service interface--
was:
-Re-design and refactoring of Scorecard model in kie-pmml module. The result of which should be...
* Scorecard models uses a standardized "pipeline" for processing requests to apply a model to input data
* Scorecard models use the "re-usable alpha network" approach when possible, minimizing the use of KieSessions and rete.
* Scorecard models use a minimal amount of rules when applying the model to input data, and any generated rules should be in executable model form/format
* Scorecard models are applied via a service interface-
> Refactor of Scorecards
> ----------------------
>
> Key: DROOLS-4589
> URL: https://issues.redhat.com/browse/DROOLS-4589
> Project: Drools
> Issue Type: Task
> Components: PMML
> Reporter: Lance Leverich
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: CustomerFocusTeam, TrustyAI
>
> --Re-design and refactoring of Scorecard model in kie-pmml module. The result of which should be...
> * Scorecard models uses a standardized "pipeline" for processing requests to apply a model to input data
> * Scorecard models use the "re-usable alpha network" approach when possible, minimizing the use of KieSessions and rete.
> * Scorecard models use a minimal amount of rules when applying the model to input data, and any generated rules should be in executable model form/format
> * Scorecard models are applied via a service interface--
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFCORE-4923) read-resource operation does not resolve expressions recursively
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4923?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4923:
--------------------------------
Summary: read-resource operation does not resolve expressions recursively (was: wildfly should resolve expression recursively)
> read-resource operation does not resolve expressions recursively
> ----------------------------------------------------------------
>
> Key: WFCORE-4923
> URL: https://issues.redhat.com/browse/WFCORE-4923
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 12.0.0.Beta1
> Reporter: Tamás Ábele
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: hal-error1.png, hal-error2.png
>
>
> The problem affects all versions. The wildfly controller does not resolve expression resursively which causes improper behaviour of the jbos CLI.
> {code:json}
> [standalone@localhost:9992 /] /subsystem=batch-jberet:read-resource(include-runtime=true,recursive=true,resolve-expressions=true)
> {
> "outcome" => "success",
> "result" => {
> "restart-jobs-on-resume" => true,
> "security-domain" => undefined,
> "default-job-repository" => "in-memory",
> "default-thread-pool" => "batch",
> "in-memory-job-repository" => {"in-memory" => {}},
> "jdbc-job-repository" => undefined,
> "thread-factory" => undefined,
> "thread-pool" => {"batch" => {
> "active-count" => 0,
> "completed-task-count" => 0L,
> "current-thread-count" => 0,
> "keepalive-time" => {
> "time" => 30L,
> "unit" => "SECONDS"
> },
> "largest-thread-count" => 0,
> "max-threads" => expression "${batch-max-threads}",
> "name" => "batch",
> "queue-size" => 0,
> "rejected-count" => 0,
> "task-count" => 0L,
> "thread-factory" => undefined
> }}
> }
> }
> {code}
> The missing recursive expression resolvation also causes runtime errors in the wildfly console (HAL) if you use properties your configuration XML-s (standalone.xml, domain.xml, ...) Two examples can be found in the attachements.
> The solution would be only adding the
> {code:java}
> rrOp.get(ModelDescriptionConstants.RESOLVE_EXPRESSIONS).set(resolve);
> {code}
> line after
> {code:java}
> rrOp.get(ModelDescriptionConstants.INCLUDE_DEFAULTS).set(defaults);
> {code}
> in the doExecuteInternal method of the
> \controller\src\main\java\org\jboss\as\controller\operations\global\ReadResourceHandler.java
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFCORE-4923) wildfly should resolve expression recursively
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4923?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4923:
--------------------------------
Affects Version/s: 12.0.0.Beta1
> wildfly should resolve expression recursively
> ---------------------------------------------
>
> Key: WFCORE-4923
> URL: https://issues.redhat.com/browse/WFCORE-4923
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 12.0.0.Beta1
> Reporter: Tamás Ábele
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: hal-error1.png, hal-error2.png
>
>
> The problem affects all versions. The wildfly controller does not resolve expression resursively which causes improper behaviour of the jbos CLI.
> {code:json}
> [standalone@localhost:9992 /] /subsystem=batch-jberet:read-resource(include-runtime=true,recursive=true,resolve-expressions=true)
> {
> "outcome" => "success",
> "result" => {
> "restart-jobs-on-resume" => true,
> "security-domain" => undefined,
> "default-job-repository" => "in-memory",
> "default-thread-pool" => "batch",
> "in-memory-job-repository" => {"in-memory" => {}},
> "jdbc-job-repository" => undefined,
> "thread-factory" => undefined,
> "thread-pool" => {"batch" => {
> "active-count" => 0,
> "completed-task-count" => 0L,
> "current-thread-count" => 0,
> "keepalive-time" => {
> "time" => 30L,
> "unit" => "SECONDS"
> },
> "largest-thread-count" => 0,
> "max-threads" => expression "${batch-max-threads}",
> "name" => "batch",
> "queue-size" => 0,
> "rejected-count" => 0,
> "task-count" => 0L,
> "thread-factory" => undefined
> }}
> }
> }
> {code}
> The missing recursive expression resolvation also causes runtime errors in the wildfly console (HAL) if you use properties your configuration XML-s (standalone.xml, domain.xml, ...) Two examples can be found in the attachements.
> The solution would be only adding the
> {code:java}
> rrOp.get(ModelDescriptionConstants.RESOLVE_EXPRESSIONS).set(resolve);
> {code}
> line after
> {code:java}
> rrOp.get(ModelDescriptionConstants.INCLUDE_DEFAULTS).set(defaults);
> {code}
> in the doExecuteInternal method of the
> \controller\src\main\java\org\jboss\as\controller\operations\global\ReadResourceHandler.java
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFCORE-4923) wildfly should resolve expression recursively
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4923?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4923:
--------------------------------
Component/s: Management
(was: Server)
> wildfly should resolve expression recursively
> ---------------------------------------------
>
> Key: WFCORE-4923
> URL: https://issues.redhat.com/browse/WFCORE-4923
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 12.0.0.Beta1
> Reporter: Tamás Ábele
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: hal-error1.png, hal-error2.png
>
>
> The problem affects all versions. The wildfly controller does not resolve expression resursively which causes improper behaviour of the jbos CLI.
> {code:json}
> [standalone@localhost:9992 /] /subsystem=batch-jberet:read-resource(include-runtime=true,recursive=true,resolve-expressions=true)
> {
> "outcome" => "success",
> "result" => {
> "restart-jobs-on-resume" => true,
> "security-domain" => undefined,
> "default-job-repository" => "in-memory",
> "default-thread-pool" => "batch",
> "in-memory-job-repository" => {"in-memory" => {}},
> "jdbc-job-repository" => undefined,
> "thread-factory" => undefined,
> "thread-pool" => {"batch" => {
> "active-count" => 0,
> "completed-task-count" => 0L,
> "current-thread-count" => 0,
> "keepalive-time" => {
> "time" => 30L,
> "unit" => "SECONDS"
> },
> "largest-thread-count" => 0,
> "max-threads" => expression "${batch-max-threads}",
> "name" => "batch",
> "queue-size" => 0,
> "rejected-count" => 0,
> "task-count" => 0L,
> "thread-factory" => undefined
> }}
> }
> }
> {code}
> The missing recursive expression resolvation also causes runtime errors in the wildfly console (HAL) if you use properties your configuration XML-s (standalone.xml, domain.xml, ...) Two examples can be found in the attachements.
> The solution would be only adding the
> {code:java}
> rrOp.get(ModelDescriptionConstants.RESOLVE_EXPRESSIONS).set(resolve);
> {code}
> line after
> {code:java}
> rrOp.get(ModelDescriptionConstants.INCLUDE_DEFAULTS).set(defaults);
> {code}
> in the doExecuteInternal method of the
> \controller\src\main\java\org\jboss\as\controller\operations\global\ReadResourceHandler.java
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFCORE-4923) wildfly should resolve expression recursively
by Tamás Ábele (Jira)
[ https://issues.redhat.com/browse/WFCORE-4923?page=com.atlassian.jira.plug... ]
Tamás Ábele updated WFCORE-4923:
--------------------------------
Description:
The problem affects all versions. The wildfly controller does not resolve expression resursively which causes improper behaviour of the jbos CLI.
{code:json}
[standalone@localhost:9992 /] /subsystem=batch-jberet:read-resource(include-runtime=true,recursive=true,resolve-expressions=true)
{
"outcome" => "success",
"result" => {
"restart-jobs-on-resume" => true,
"security-domain" => undefined,
"default-job-repository" => "in-memory",
"default-thread-pool" => "batch",
"in-memory-job-repository" => {"in-memory" => {}},
"jdbc-job-repository" => undefined,
"thread-factory" => undefined,
"thread-pool" => {"batch" => {
"active-count" => 0,
"completed-task-count" => 0L,
"current-thread-count" => 0,
"keepalive-time" => {
"time" => 30L,
"unit" => "SECONDS"
},
"largest-thread-count" => 0,
"max-threads" => expression "${batch-max-threads}",
"name" => "batch",
"queue-size" => 0,
"rejected-count" => 0,
"task-count" => 0L,
"thread-factory" => undefined
}}
}
}
{code}
The missing recursive expression resolvation also causes runtime errors in the wildfly console (HAL) if you use properties your configuration XML-s (standalone.xml, domain.xml, ...) Two examples can be found in the attachements.
The solution would be only adding the
{code:java}
rrOp.get(ModelDescriptionConstants.RESOLVE_EXPRESSIONS).set(resolve);
{code}
line after
{code:java}
rrOp.get(ModelDescriptionConstants.INCLUDE_DEFAULTS).set(defaults);
{code}
in the doExecuteInternal method of the
\controller\src\main\java\org\jboss\as\controller\operations\global\ReadResourceHandler.java
was:
The problem affects all versions. The wildfly controller does not resolve expression resursively which causes improper behaviour of the jbos CLI.
{code:json}
[standalone@localhost:9992 /] /subsystem=batch-jberet:read-resource(include-runtime=true,recursive=true,resolve-expressions=true)
{
"outcome" => "success",
"result" => {
"restart-jobs-on-resume" => true,
"security-domain" => undefined,
"default-job-repository" => "in-memory",
"default-thread-pool" => "batch",
"in-memory-job-repository" => {"in-memory" => {}},
"jdbc-job-repository" => undefined,
"thread-factory" => undefined,
"thread-pool" => {"batch" => {
"active-count" => 0,
"completed-task-count" => 0L,
"current-thread-count" => 0,
"keepalive-time" => {
"time" => 30L,
"unit" => "SECONDS"
},
"largest-thread-count" => 0,
"max-threads" => expression "${batch-max-threads}",
"name" => "batch",
"queue-size" => 0,
"rejected-count" => 0,
"task-count" => 0L,
"thread-factory" => undefined
}}
}
}
{code}
The missing recursive expression resolvation also causes runtime errors in the wildfly console (HAL) if you use properties your configuration XML-s (standalone.xml, domain.xml, ...) Two examples can be found in the attachements.
> wildfly should resolve expression recursively
> ---------------------------------------------
>
> Key: WFCORE-4923
> URL: https://issues.redhat.com/browse/WFCORE-4923
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Tamás Ábele
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: hal-error1.png, hal-error2.png
>
>
> The problem affects all versions. The wildfly controller does not resolve expression resursively which causes improper behaviour of the jbos CLI.
> {code:json}
> [standalone@localhost:9992 /] /subsystem=batch-jberet:read-resource(include-runtime=true,recursive=true,resolve-expressions=true)
> {
> "outcome" => "success",
> "result" => {
> "restart-jobs-on-resume" => true,
> "security-domain" => undefined,
> "default-job-repository" => "in-memory",
> "default-thread-pool" => "batch",
> "in-memory-job-repository" => {"in-memory" => {}},
> "jdbc-job-repository" => undefined,
> "thread-factory" => undefined,
> "thread-pool" => {"batch" => {
> "active-count" => 0,
> "completed-task-count" => 0L,
> "current-thread-count" => 0,
> "keepalive-time" => {
> "time" => 30L,
> "unit" => "SECONDS"
> },
> "largest-thread-count" => 0,
> "max-threads" => expression "${batch-max-threads}",
> "name" => "batch",
> "queue-size" => 0,
> "rejected-count" => 0,
> "task-count" => 0L,
> "thread-factory" => undefined
> }}
> }
> }
> {code}
> The missing recursive expression resolvation also causes runtime errors in the wildfly console (HAL) if you use properties your configuration XML-s (standalone.xml, domain.xml, ...) Two examples can be found in the attachements.
> The solution would be only adding the
> {code:java}
> rrOp.get(ModelDescriptionConstants.RESOLVE_EXPRESSIONS).set(resolve);
> {code}
> line after
> {code:java}
> rrOp.get(ModelDescriptionConstants.INCLUDE_DEFAULTS).set(defaults);
> {code}
> in the doExecuteInternal method of the
> \controller\src\main\java\org\jboss\as\controller\operations\global\ReadResourceHandler.java
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (DROOLS-4746) UX for DMN "quick test" tool
by Elizabeth Clayton (Jira)
[ https://issues.redhat.com/browse/DROOLS-4746?page=com.atlassian.jira.plug... ]
Elizabeth Clayton resolved DROOLS-4746.
---------------------------------------
Resolution: Done
[~karreiro][~tirelli] I made the changes that we discussed, so I'm going to go ahead and mark this resolved. But do let me know if you need any additional changes. Thanks!
> UX for DMN "quick test" tool
> ----------------------------
>
> Key: DROOLS-4746
> URL: https://issues.redhat.com/browse/DROOLS-4746
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Fine.png, Screen Shot 2020-04-08 at 4.34.49 PM.png, Screen Shot 2020-04-08 at 5.01.51 PM.png, Screen Shot 2020-04-09 at 9.29.34 AM.png, decision-logic-2-2.png, decision-logic-3-2.png
>
>
> As a DMN author, I'd like to probe the DMN model during the authoring phase without leaving the DMN Editor. Actually, it's really important to explore the DMN model to understand with values are required by the test.
> When the user run the test he can get back the results of the DMN execution.
> Moreover, it would be handy to add those input/output to an existing (or new) test scenario.
> *Acceptance criteria*
> Users are able to:
> * Execute a single node boxed expression by providing node inputs (within the DMN editor.)
> * Explore the DMN model and provide inputs necessary to run a scenario test.
> * Obtain results (Expected) within the DMN editor once the test is run.
> Notes:
> * Try to dissociate this feature from the "test scenario" concept and think of this more as a partial execution. When we're thinking about the concept of a "test scenario", we think about input values and expected outputs... however, in this new component, users will be able to provide inputs and just check the current output.
> * Out of scope: Saving or exporting the "quick test."
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFCORE-4923) wildfly should resolve expression recursively
by Tamás Ábele (Jira)
[ https://issues.redhat.com/browse/WFCORE-4923?page=com.atlassian.jira.plug... ]
Tamás Ábele updated WFCORE-4923:
--------------------------------
Attachment: hal-error1.png
> wildfly should resolve expression recursively
> ---------------------------------------------
>
> Key: WFCORE-4923
> URL: https://issues.redhat.com/browse/WFCORE-4923
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Tamás Ábele
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: hal-error1.png, hal-error2.png
>
>
> The problem affects all versions. The wildfly controller does not resolve expression resursively which causes improper behaviour of the jbos CLI.
> {code:json}
> [standalone@localhost:9992 /] /subsystem=batch-jberet:read-resource(include-runtime=true,recursive=true,resolve-expressions=true)
> {
> "outcome" => "success",
> "result" => {
> "restart-jobs-on-resume" => true,
> "security-domain" => undefined,
> "default-job-repository" => "in-memory",
> "default-thread-pool" => "batch",
> "in-memory-job-repository" => {"in-memory" => {}},
> "jdbc-job-repository" => undefined,
> "thread-factory" => undefined,
> "thread-pool" => {"batch" => {
> "active-count" => 0,
> "completed-task-count" => 0L,
> "current-thread-count" => 0,
> "keepalive-time" => {
> "time" => 30L,
> "unit" => "SECONDS"
> },
> "largest-thread-count" => 0,
> "max-threads" => expression "${batch-max-threads}",
> "name" => "batch",
> "queue-size" => 0,
> "rejected-count" => 0,
> "task-count" => 0L,
> "thread-factory" => undefined
> }}
> }
> }
> {code}
> The missing recursive expression resolvation also causes runtime errors in the wildfly console (HAL) if you use properties your configuration XML-s (standalone.xml, domain.xml, ...)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months