[JBoss JIRA] (DROOLS-5539) Review dmn examples version in codebase
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5539?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5539:
-----------------------------------
Description:
Motivation: avoid a User might find *easily* an outdated version (DMN v1.1) in the examples from our codebase.
Goal: review dmn examples version in codebase to make sure there are no "default" v1.1 model to be found, that are properly isolated in specific packages and/or specific test infrastructure.
Impacts: kie-dmn codebase in drools.git and downstream repos to be assessed.
was:Review dmn example version in codebase to make sure there are no "default" v1.1 model to be found, that are properly isolated in specific packages or specific test infrastructure.
> Review dmn examples version in codebase
> ---------------------------------------
>
> Key: DROOLS-5539
> URL: https://issues.redhat.com/browse/DROOLS-5539
> Project: Drools
> Issue Type: Epic
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> Motivation: avoid a User might find *easily* an outdated version (DMN v1.1) in the examples from our codebase.
> Goal: review dmn examples version in codebase to make sure there are no "default" v1.1 model to be found, that are properly isolated in specific packages and/or specific test infrastructure.
> Impacts: kie-dmn codebase in drools.git and downstream repos to be assessed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (DROOLS-5539) Review dmn examples version in codebase
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5539?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5539:
-----------------------------------
Description:
*Motivation*: avoid a User might find *_easily_* an outdated version (DMN v1.1) in the examples from our codebase.
*Goal*: review dmn examples version in codebase to make sure there are no "default" v1.1 model to be found, that are properly isolated in specific packages and/or specific test infrastructure.
*Impacts*: kie-dmn codebase in drools.git and downstream repos to be assessed.
was:
Motivation: avoid a User might find *easily* an outdated version (DMN v1.1) in the examples from our codebase.
Goal: review dmn examples version in codebase to make sure there are no "default" v1.1 model to be found, that are properly isolated in specific packages and/or specific test infrastructure.
Impacts: kie-dmn codebase in drools.git and downstream repos to be assessed.
> Review dmn examples version in codebase
> ---------------------------------------
>
> Key: DROOLS-5539
> URL: https://issues.redhat.com/browse/DROOLS-5539
> Project: Drools
> Issue Type: Epic
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> *Motivation*: avoid a User might find *_easily_* an outdated version (DMN v1.1) in the examples from our codebase.
> *Goal*: review dmn examples version in codebase to make sure there are no "default" v1.1 model to be found, that are properly isolated in specific packages and/or specific test infrastructure.
> *Impacts*: kie-dmn codebase in drools.git and downstream repos to be assessed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (DROOLS-5539) Review dmn examples version in codebase
by Matteo Mortari (Jira)
Matteo Mortari created DROOLS-5539:
--------------------------------------
Summary: Review dmn examples version in codebase
Key: DROOLS-5539
URL: https://issues.redhat.com/browse/DROOLS-5539
Project: Drools
Issue Type: Story
Components: dmn engine
Reporter: Matteo Mortari
Assignee: Matteo Mortari
Review dmn example version in codebase to make sure there are no "default" v1.1 model to be found, that are properly isolated in specific packages or specific test infrastructure.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (DROOLS-5538) DMN strongly typed class compile errors for collection types
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-5538:
-----------------------------------------
Summary: DMN strongly typed class compile errors for collection types
Key: DROOLS-5538
URL: https://issues.redhat.com/browse/DROOLS-5538
Project: Drools
Issue Type: Bug
Components: dmn engine
Affects Versions: 7.40.0.Final
Reporter: Toshiya Kobayashi
Assignee: Toshiya Kobayashi
If we have an itemDefinition with isCollection="true", it will cause a compile error for InputSet and OutputSet when typesafe is enabled. Note that itemComponent with isCollection="true" works fine.
DMNRuntimeTypesTest.testCollectionType()
{code:xml}
<semantic:itemDefinition label="tPersonList" name="tPersonList" isCollection="true">
<semantic:typeRef>tPerson</semantic:typeRef>
</semantic:itemDefinition>
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFCORE-5070) List to Set ParameterCorrectors and ParameterValidators
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-5070?page=com.atlassian.jira.plug... ]
Brian Stansberry updated WFCORE-5070:
-------------------------------------
Description:
The management API doesn't have a "SET" attribute/parameter type but use cases like JBEAP-19958 shows there's some need for a bit of set-like behavior.
Idea here is the controller module could expose some static factories for ParameterCorrectors and ParameterValidators to impose set semantics on a ModelType.LIST attribute.
A validator would be used to reject lists with duplicates.
A corrector would be used to remove dups from a list without failing.
For a corrector construction could perhaps be parameterized by allowing passing in the name of the attribute and a log level. Those would be used to log when the corrector removes duplicates. The corrector would definitely need to know the attribute name to log an appropriate message. The appropriate level for a message may vary based on the attribute.
was:
The management API doesn't have a "SET" attribute/parameter type but use cases like JBEAP-19958 shows there's some need.
Idea here is the controller module could expose some static factories for ParameterCorrectors and ParameterValidators to impose set semantics on a ModelType.LIST attribute.
A validator would be used to reject lists with duplicates.
A corrector would be used to remove dups from a list without failing.
For a corrector construction could perhaps be parameterized by allowing passing in the name of the attribute and a log level. Those would be used to log when the corrector removes duplicates. The corrector would definitely need to know the attribute name to log an appropriate message. The appropriate level for a message may vary based on the attribute.
> List to Set ParameterCorrectors and ParameterValidators
> -------------------------------------------------------
>
> Key: WFCORE-5070
> URL: https://issues.redhat.com/browse/WFCORE-5070
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
> Priority: Minor
>
> The management API doesn't have a "SET" attribute/parameter type but use cases like JBEAP-19958 shows there's some need for a bit of set-like behavior.
> Idea here is the controller module could expose some static factories for ParameterCorrectors and ParameterValidators to impose set semantics on a ModelType.LIST attribute.
> A validator would be used to reject lists with duplicates.
> A corrector would be used to remove dups from a list without failing.
> For a corrector construction could perhaps be parameterized by allowing passing in the name of the attribute and a log level. Those would be used to log when the corrector removes duplicates. The corrector would definitely need to know the attribute name to log an appropriate message. The appropriate level for a message may vary based on the attribute.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFCORE-5070) List to Set ParameterCorrectors and ParameterValidators
by Brian Stansberry (Jira)
Brian Stansberry created WFCORE-5070:
----------------------------------------
Summary: List to Set ParameterCorrectors and ParameterValidators
Key: WFCORE-5070
URL: https://issues.redhat.com/browse/WFCORE-5070
Project: WildFly Core
Issue Type: Enhancement
Components: Management
Reporter: Brian Stansberry
Assignee: Jeff Mesnil
The management API doesn't have a "SET" attribute/parameter type but use cases like JBEAP-19958 shows there's some need.
Idea here is the controller module could expose some static factories for ParameterCorrectors and ParameterValidators to impose set semantics on a ModelType.LIST attribute.
A validator would be used to reject lists with duplicates.
A corrector would be used to remove dups from a list without failing.
For a corrector construction could perhaps be parameterized by allowing passing in the name of the attribute and a log level. Those would be used to log when the corrector removes duplicates. The corrector would definitely need to know the attribute name to log an appropriate message. The appropriate level for a message may vary based on the attribute.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months