July 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5467) Rule Names are not converted GDST <-> XLS

by Jozef Marko (Jira)

Jozef Marko created DROOLS-5467: ----------------------------------- Summary: Rule Names are not converted GDST <-> XLS Key: DROOLS-5467 URL: https://issues.redhat.com/browse/DROOLS-5467 Project: Drools Issue Type: Bug Components: Guided Decision Table Editor, XLS Decision Table Editor Affects Versions: 7.39.0.Final Reporter: Jozef Marko Assignee: Toni Rikkola After DROOLS-5333 we should ensure custom rule names are correctly converted in both ways GDST->XLS and XLS->GDST. Currently even if in GDST we declared custom rule names in the converted XLS are used some autogonerated values as [tablename_rowindex]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5466) [DMN Designer] validation of included BKM invocation

by Jozef Marko (Jira)

Jozef Marko created DROOLS-5466: ----------------------------------- Summary: [DMN Designer] validation of included BKM invocation Key: DROOLS-5466 URL: https://issues.redhat.com/browse/DROOLS-5466 Project: Drools Issue Type: Bug Components: DMN Editor Affects Versions: 7.37.0.Final Reporter: Jozef Marko Assignee: Guilherme Gomes Attachments: MySpace_Traffic_Violation.zip Issue found during DROOLS-5229 review however it is present also in master. The issue is if user tries to invoke a BKM/function from included DMN model and alias of this model contain dots. In such case validation fails. The attached Traffic Violation sample was artificially amended to demonstrate the issue. There were added two context entries (Comparison and Comparison-2) in the Should be the driver suspended. Both logically equal. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5387) Rule Names are not converted GDST <-> XLS

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-5387?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-5387: -------------------------------- Summary: Rule Names are not converted GDST <-> XLS (was: Rule Names are converted GDST <-> XLS) > Rule Names are not converted GDST <-> XLS > ----------------------------------------- > > Key: DROOLS-5387 > URL: https://issues.redhat.com/browse/DROOLS-5387 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor, XLS Decision Table Editor > Affects Versions: 7.39.0.Final > Reporter: Jozef Marko > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > > After DROOLS-5333 we should ensure custom rule names are correctly converted in both ways GDST->XLS and XLS->GDST. > Currently even if in GDST we declared custom rule names in the converted XLS are used some autogonerated values as [tablename_rowindex]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5379) Add more accumulate with static method tests

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5379?page=com.atlassian.jira.plug... ] Toshiya Kobayashi resolved DROOLS-5379. --------------------------------------- Fix Version/s: 7.40.0.Final Resolution: Done Closing as done by DROOLS-5386 > Add more accumulate with static method tests > -------------------------------------------- > > Key: DROOLS-5379 > URL: https://issues.redhat.com/browse/DROOLS-5379 > Project: Drools > Issue Type: Sub-task > Components: executable model > Affects Versions: 7.38.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > Fix For: 7.40.0.Final > > > Add more accumulate tests for stability. Especially, variants of testAccumulateOnStaticMethod(). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5396) Undo and Redo keyboard shortcuts do not work in grid editor

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-5396?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-5396: -------------------------------- Priority: Major (was: Minor) > Undo and Redo keyboard shortcuts do not work in grid editor > ----------------------------------------------------------- > > Key: DROOLS-5396 > URL: https://issues.redhat.com/browse/DROOLS-5396 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.39.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > We have these shortcuts in DMN designer > - Undo Ctrl+Z > - Redo Ctrl+Shift+Z > They work fine on graph editor. However they do not work in grid editor. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5379) Add more accumulate with static method tests

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5379?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5379: -------------------------------------- Story Points: 1 (was: 3) > Add more accumulate with static method tests > -------------------------------------------- > > Key: DROOLS-5379 > URL: https://issues.redhat.com/browse/DROOLS-5379 > Project: Drools > Issue Type: Sub-task > Components: executable model > Affects Versions: 7.38.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Add more accumulate tests for stability. Especially, variants of testAccumulateOnStaticMethod(). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13639) Avoid duplicate expiration scheduling on member leave for non-tx invalidation cache

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13639?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13639: -------------------------------- Description: Following WFLY-13627, a non-tx invalidation cache will schedule session/SFSB expiration on the local member. When that member leaves, the expiration will be reschedule on the primary owner of segment 0 (in a non-tx cache, all entries map to segment 0). However, since that member cannot distinguish which sessions/SFSBs were owned by the leaving member, it must schedule all sessions/SFSBs. By storing the address of the member that handled a given request along with a web session/SFSBs metadata, we can discriminate which entries require expiration rescheduling on topology change for non-tx invalidation caches. was:By storing the address of the member that handled a given request along with a web session/SFSBs metadata, we can discriminate which entries require expiration rescheduling on topology change for non-tx invalidation caches. > Avoid duplicate expiration scheduling on member leave for non-tx invalidation cache > ----------------------------------------------------------------------------------- > > Key: WFLY-13639 > URL: https://issues.redhat.com/browse/WFLY-13639 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 20.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Following WFLY-13627, a non-tx invalidation cache will schedule session/SFSB expiration on the local member. When that member leaves, the expiration will be reschedule on the primary owner of segment 0 (in a non-tx cache, all entries map to segment 0). However, since that member cannot distinguish which sessions/SFSBs were owned by the leaving member, it must schedule all sessions/SFSBs. > By storing the address of the member that handled a given request along with a web session/SFSBs metadata, we can discriminate which entries require expiration rescheduling on topology change for non-tx invalidation caches. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13639) Avoid duplicate expiration scheduling on member leave for non-tx invalidation cache

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13639: ----------------------------------- Summary: Avoid duplicate expiration scheduling on member leave for non-tx invalidation cache Key: WFLY-13639 URL: https://issues.redhat.com/browse/WFLY-13639 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 20.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro By storing the address of the member that handled a given request along with a web session/SFSBs metadata, we can discriminate which entries require expiration rescheduling on topology change for non-tx invalidation caches. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13638) Permit multiples applications to the same server registry a MP openapi endpoint

by Rhuan Rocha (Jira)

[ https://issues.redhat.com/browse/WFLY-13638?page=com.atlassian.jira.plugi... ] Rhuan Rocha updated WFLY-13638: ------------------------------- Description: In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code: [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] It makes sense as the endpoint is registered to http://{host}:\{port}/openpi, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to http://{host}:\{port}/\{context-root}/openapi. Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. was: In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code: [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] It makes sense as the endpoint is registered to http://{host}:\{port}/openpi, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to http://{host}:\{port}/\{context-root}/openapi. Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. > Permit multiples applications to the same server registry a MP openapi endpoint > ------------------------------------------------------------------------------- > > Key: WFLY-13638 > URL: https://issues.redhat.com/browse/WFLY-13638 > Project: WildFly > Issue Type: Feature Request > Components: MP OpenAPI > Affects Versions: 20.0.0.Final > Reporter: Rhuan Rocha > Assignee: Paul Ferraro > Priority: Major > > In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code: > [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] > > It makes sense as the endpoint is registered to http://{host}:\{port}/openpi, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to http://{host}:\{port}/\{context-root}/openapi. Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13638) Permit multiples applications to the same server registry a MP openapi endpoint

by Rhuan Rocha (Jira)

[ https://issues.redhat.com/browse/WFLY-13638?page=com.atlassian.jira.plugi... ] Rhuan Rocha updated WFLY-13638: ------------------------------- Description: In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code: [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] It makes sense as the endpoint is registered to http://{host}:\{port}/openpi, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to http://{host}:\{port}/\{context-root}/openapi. Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. was: In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code: [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] It makes sense as the endpoint is registered to _http://{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. > Permit multiples applications to the same server registry a MP openapi endpoint > ------------------------------------------------------------------------------- > > Key: WFLY-13638 > URL: https://issues.redhat.com/browse/WFLY-13638 > Project: WildFly > Issue Type: Feature Request > Components: MP OpenAPI > Affects Versions: 20.0.0.Final > Reporter: Rhuan Rocha > Assignee: Paul Ferraro > Priority: Major > > In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code: > [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...] > > It makes sense as the endpoint is registered to http://{host}:\{port}/openpi, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to http://{host}:\{port}/\{context-root}/openapi. Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users. -- 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