July 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5442) [Guided Decision Table] Key navigation failure in Descision table

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-5442?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-5442: ------------------------------------- Sent PR is in draft state as the component is general. Checking if tests of other repositories are not affected. Then tests for actual changes will be provided. > [Guided Decision Table] Key navigation failure in Descision table > ----------------------------------------------------------------- > > Key: DROOLS-5442 > URL: https://issues.redhat.com/browse/DROOLS-5442 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 7.39.0.Final > Reporter: Anna Dupliak > Assignee: Jozef Marko > Priority: Major > Labels: decision_table, drools-tools > Attachments: arrow.webm, image-2020-06-18-15-04-15-605.png, image-2020-06-18-15-06-26-220.png > > > When user navigates among columns from Description to any other - he need to push right arrow key twice to skip a hidden column introduced recently for decision tables. > !image-2020-06-18-15-04-15-605.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5465) [Guided Decision Table] Key navigation failure in Descision table

by Jozef Marko (Jira)

Jozef Marko created DROOLS-5465: ----------------------------------- Summary: [Guided Decision Table] Key navigation failure in Descision table Key: DROOLS-5465 URL: https://issues.redhat.com/browse/DROOLS-5465 Project: Drools Issue Type: Bug Components: Guided Decision Table Editor Affects Versions: 7.39.0.Final Reporter: Jozef Marko Assignee: Jozef Marko Attachments: arrow.webm, image-2020-06-18-15-04-15-605.png, image-2020-06-18-15-06-26-220.png When user navigates among columns from Description to any other - he need to push right arrow key twice to skip a hidden column introduced recently for decision tables. !image-2020-06-18-15-04-15-605.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5442) [Guided Decision Table] Key navigation failure in Descision table

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-5442?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-5442: -------------------------------- Tester: Jan Stastny (was: Jozef Marko) > [Guided Decision Table] Key navigation failure in Descision table > ----------------------------------------------------------------- > > Key: DROOLS-5442 > URL: https://issues.redhat.com/browse/DROOLS-5442 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 7.39.0.Final > Reporter: Anna Dupliak > Assignee: Jozef Marko > Priority: Major > Labels: decision_table, drools-tools > Attachments: arrow.webm, image-2020-06-18-15-04-15-605.png, image-2020-06-18-15-06-26-220.png > > > When user navigates among columns from Description to any other - he need to push right arrow key twice to skip a hidden column introduced recently for decision tables. > !image-2020-06-18-15-04-15-605.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5442) [Guided Decision Table] Key navigation failure in Descision table

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-5442?page=com.atlassian.jira.plug... ] Jozef Marko reassigned DROOLS-5442: ----------------------------------- Assignee: Jozef Marko (was: Toni Rikkola) > [Guided Decision Table] Key navigation failure in Descision table > ----------------------------------------------------------------- > > Key: DROOLS-5442 > URL: https://issues.redhat.com/browse/DROOLS-5442 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor > Affects Versions: 7.39.0.Final > Reporter: Anna Dupliak > Assignee: Jozef Marko > Priority: Major > Labels: decision_table, drools-tools > Attachments: arrow.webm, image-2020-06-18-15-04-15-605.png, image-2020-06-18-15-06-26-220.png > > > When user navigates among columns from Description to any other - he need to push right arrow key twice to skip a hidden column introduced recently for decision tables. > !image-2020-06-18-15-04-15-605.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5272) Re-evaluate/refactor KiePMML AST factories

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5272?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-5272: ------------------------------------- Description: Re-evaluate implementation of KiePMML AST factories in the view of the mining model specifications. Reevaluate usage of fieldTypeMap - types. E.g.: inside DroolsModelProvider.getKiePMMLDroolsASTCommon the Map<String, KiePMMLOriginalTypeGeneratedType> fieldTypeMap is populated invoking addTransformationsDerivedFields. Then, a List<KiePMMLDroolsType> is created out of this map. Later the same map is also populated by KiePMMLDataDictionaryASTFactory.factory(fieldTypeMap).declareTypes(dataDictionary). and the List<KiePMMLDroolsType> retrieved by the latter are added to the one created before. That means it is not needed to have KiePMMLDerivedFieldASTFactory and KiePMMLDataDictionaryASTFactory returning List<KiePMMLDroolsType> - they can simply instantiate and return a Map<String, KiePMMLOriginalTypeGeneratedType>; the maps may be merged together, and the List<KiePMMLDroolsType> may be created out of that (merged) map. So 1) KiePMMLDataDictionaryASTFactory and KiePMMLDerivedFieldASTFactory should return only a newly instantiated Map<String, KiePMMLOriginalTypeGeneratedType> 2) inside DroolsModelProvider.getKiePMMLDroolsASTCommon those maps should be merged 3) List<KiePMMLDroolsType> should be created out of the merged map 4) merged map and List<KiePMMLDroolsType> should be propagated as parameters was:Re-evaluate implementation of KiePMML AST factories in the view of the mining model specifications. > Re-evaluate/refactor KiePMML AST factories > ------------------------------------------ > > Key: DROOLS-5272 > URL: https://issues.redhat.com/browse/DROOLS-5272 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Re-evaluate implementation of KiePMML AST factories in the view of the mining model specifications. > Reevaluate usage of fieldTypeMap - types. > > E.g.: inside > DroolsModelProvider.getKiePMMLDroolsASTCommon the > Map<String, KiePMMLOriginalTypeGeneratedType> fieldTypeMap is populated invoking > addTransformationsDerivedFields. Then, a List<KiePMMLDroolsType> is created out of this map. > Later the same map is also populated by > KiePMMLDataDictionaryASTFactory.factory(fieldTypeMap).declareTypes(dataDictionary). > and the List<KiePMMLDroolsType> retrieved by the latter are added to the one created before. > That means it is not needed to have KiePMMLDerivedFieldASTFactory and KiePMMLDataDictionaryASTFactory returning List<KiePMMLDroolsType> - they can simply instantiate and return a Map<String, KiePMMLOriginalTypeGeneratedType>; the maps may be merged together, and the List<KiePMMLDroolsType> may be created out of that (merged) map. > So > 1) KiePMMLDataDictionaryASTFactory and KiePMMLDerivedFieldASTFactory should return only a newly instantiated Map<String, KiePMMLOriginalTypeGeneratedType> > 2) inside DroolsModelProvider.getKiePMMLDroolsASTCommon those maps should be merged > 3) List<KiePMMLDroolsType> should be created out of the merged map > 4) merged map and List<KiePMMLDroolsType> should be propagated as parameters -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5464) Declare kie-pmml-dependencies management

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5464?page=com.atlassian.jira.plug... ] Gabriele Cardosi closed DROOLS-5464. ------------------------------------ > Declare kie-pmml-dependencies management > ---------------------------------------- > > Key: DROOLS-5464 > URL: https://issues.redhat.com/browse/DROOLS-5464 > Project: Drools > Issue Type: Feature Request > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Declare kie-pmml-dependencies version inside kie-parent dependencyManagement -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5462) Provide default model name for Pmml models without it

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5462?page=com.atlassian.jira.plug... ] Gabriele Cardosi closed DROOLS-5462. ------------------------------------ > Provide default model name for Pmml models without it > ----------------------------------------------------- > > Key: DROOLS-5462 > URL: https://issues.redhat.com/browse/DROOLS-5462 > Project: Drools > Issue Type: Feature Request > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > modelName attribute is not mandatory from PMML specs. > With this ticket a "default" one will be provided soon after pmml file is "unmarshalled" to pmml java instance. > Generated name would be > _Pmml File Name_ + _model type_ + _index_ (inside models list) > e.g. > > Pmml File "TestSample.pmml" > Model type "Regression" > Position : second (index =1) > > generated modelName > _TestSampleRegression1_ > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13632) If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/WFLY-13632?page=com.atlassian.jira.plugi... ] Thomas Jenkinson commented on WFLY-13632: ----------------------------------------- If CMR can be processed for deployment in parallel by whatever component processes the standalone.xml then this situation can occur. For a standalone.xml if Thread 1 deploys CMR resource 1 concurrently with Thread 2 deploying CMR resource 2 then this can happen. Alternatively the CLI being used concurrently to add two CMR resources. > If a CMR resource is deployed concurrently then it will overwrite the list of resources that are expected to behave as CMR > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13632 > URL: https://issues.redhat.com/browse/WFLY-13632 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > Inspecting https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... we can see that it will overwrite the map in https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... because it first get's a copy of a map (https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... -> https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060...) so the maps won't be equal. > This will result in WildFly overwriting the list of resources that Narayana will treat as CMR. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13633) Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/WFLY-13633?page=com.atlassian.jira.plugi... ] Ondrej Chaloupka edited comment on WFLY-13633 at 7/1/20 8:51 AM: ----------------------------------------------------------------- The {{:reload}} won't protect here as the {{:reload}} operation does not restart JVM. And the removal has not impact on the internal Narayana map which is saved in the static variable. was (Author: ochaloup): The {{:reload}} won't protect here as the {{:reload}} operation will have not impact on the internal Narayana map which is saved in the static variable. > Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR > ------------------------------------------------------------------------------------- > > Key: WFLY-13633 > URL: https://issues.redhat.com/browse/WFLY-13633 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... does not remove the JNDI name from the list of names that Narayana will treat as CMR resources as it is removed from a copy of the map: https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... > This means that if Narayana encounters another resource at a later time with the same JNDI name it will consider it is a CMR resource. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13633) Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/WFLY-13633?page=com.atlassian.jira.plugi... ] Ondrej Chaloupka commented on WFLY-13633: ----------------------------------------- The {{:reload}} won't protect here as the {{:reload}} operation will have not impact on the internal Narayana map which is saved in the static variable. > Undeployed CMR resource JNDI names are not deregisted as needing to be treated as CMR > ------------------------------------------------------------------------------------- > > Key: WFLY-13633 > URL: https://issues.redhat.com/browse/WFLY-13633 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... does not remove the JNDI name from the list of names that Narayana will treat as CMR resources as it is removed from a copy of the map: https://github.com/jbosstm/narayana/blob/48818111d12d2e51b52082a00bcb6060... > This means that if Narayana encounters another resource at a later time with the same JNDI name it will consider it is a CMR resource. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2020