[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4724:
--------------------------------
Description:
Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
However Error message is reported anyway to the user:
!image-2019-11-04-19-39-01-113.png|thumbnail!
This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
!image-2019-11-04-19-40-27-201.png|thumbnail!
so the current behavior is not consistent across re-open of the editor.
Let's revert this default.
The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
Currently, the DMN Compiler will throw 1 Warning.
Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
Currently, the DMN Validator schema check is not reporting any XSD violation.
h2. Manual acceptance test
Try to save default / empty
h3. Business Central
- Decision node
- BKM node
- Cleared Function
- Context entry
- Invocation
h3. Kogito
- Decision node
- BKM node
- Cleared Function
- Context entry
- Invocation
was:
Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
However Error message is reported anyway to the user:
!image-2019-11-04-19-39-01-113.png|thumbnail!
This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
!image-2019-11-04-19-40-27-201.png|thumbnail!
so the current behavior is not consistent across re-open of the editor.
Let's revert this default.
The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
Currently, the DMN Compiler will throw 1 Warning.
Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
Currently, the DMN Validator schema check is not reporting any XSD violation.
h2. Manual acceptance test
Try to save default / empty
h3. Business Central
- Decision node (?)
- BKM node (?)
- Cleared Function (?)
- Context entry (?) [^error.log] [^save-context.webm]
- Invocation (?)
h3. Kogito (/)
- Decision node
- BKM node
- Cleared Function
- Context entry
- Invocation
> [DMN Designer] Do not default to a LiteralExpression when no expression is defined
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-4724
> URL: https://issues.jboss.org/browse/DROOLS-4724
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2019-11-29 12-04-18.png, error.log, image-2019-11-04-19-39-01-113.png, image-2019-11-04-19-40-27-201.png, m.dmn, save-context.webm, screenshot-1.png, screenshot-2.png
>
>
> Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
> However Error message is reported anyway to the user:
> !image-2019-11-04-19-39-01-113.png|thumbnail!
> This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
> !image-2019-11-04-19-40-27-201.png|thumbnail!
> so the current behavior is not consistent across re-open of the editor.
> Let's revert this default.
> The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
> Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
> Currently, the DMN Compiler will throw 1 Warning.
> Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
> Currently, the DMN Validator schema check is not reporting any XSD violation.
> h2. Manual acceptance test
> Try to save default / empty
> h3. Business Central
> - Decision node
> - BKM node
> - Cleared Function
> - Context entry
> - Invocation
> h3. Kogito
> - Decision node
> - BKM node
> - Cleared Function
> - Context entry
> - Invocation
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-4724:
--------------------------------
Description:
Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
However Error message is reported anyway to the user:
!image-2019-11-04-19-39-01-113.png|thumbnail!
This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
!image-2019-11-04-19-40-27-201.png|thumbnail!
so the current behavior is not consistent across re-open of the editor.
Let's revert this default.
The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
Currently, the DMN Compiler will throw 1 Warning.
Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
Currently, the DMN Validator schema check is not reporting any XSD violation.
h2. Manual acceptance test
Try to save default / empty
h3. Business Central
- Decision node (?)
- BKM node (?)
- Cleared Function (?)
- Context entry (?) [^error.log] [^save-context.webm]
- Invocation (?)
h3. Kogito (/)
- Decision node
- BKM node
- Cleared Function
- Context entry
- Invocation
was:
Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
However Error message is reported anyway to the user:
!image-2019-11-04-19-39-01-113.png|thumbnail!
This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
!image-2019-11-04-19-40-27-201.png|thumbnail!
so the current behavior is not consistent across re-open of the editor.
Let's revert this default.
The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
Currently, the DMN Compiler will throw 1 Warning.
Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
Currently, the DMN Validator schema check is not reporting any XSD violation.
h2. Manual acceptance test
Try to save default / empty
h3. Business Central
- Decision node (?)
- BKM node (?)
- Cleared Function (?)
- Context entry (?) [^error.log] [^save-context.webm]
- Invocation (?)
h3. Kogito
- Decision node (?)
- BKM node (?)
- Cleared Function (?)
- Context entry (?)
- Invocation (?)
> [DMN Designer] Do not default to a LiteralExpression when no expression is defined
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-4724
> URL: https://issues.jboss.org/browse/DROOLS-4724
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2019-11-29 12-04-18.png, error.log, image-2019-11-04-19-39-01-113.png, image-2019-11-04-19-40-27-201.png, m.dmn, save-context.webm, screenshot-1.png, screenshot-2.png
>
>
> Currently, the DMN Editor will default to a blank LiteralExpression on Save if the user did not provide an expression for an element.
> However Error message is reported anyway to the user:
> !image-2019-11-04-19-39-01-113.png|thumbnail!
> This also as the (imho undesired) side-effect that if the user was to re-open later that file, instead of a empty element, it would be a blank LiteralExpression
> !image-2019-11-04-19-40-27-201.png|thumbnail!
> so the current behavior is not consistent across re-open of the editor.
> Let's revert this default.
> The DMN Editor on save should +not+ default to a blank LiteralExpression if the user did not provide an expression for the element.
> Once this change is applied from the f/e side, I am happy to be involved in order to assess which of the messages reported by the Validator or the Compiler are causing issue to the WB (if any).
> Currently, the DMN Compiler will throw 1 Warning.
> Currently, the DMN Validator will throw 1 Error (I can align this to be a Warn too).
> Currently, the DMN Validator schema check is not reporting any XSD violation.
> h2. Manual acceptance test
> Try to save default / empty
> h3. Business Central
> - Decision node (?)
> - BKM node (?)
> - Cleared Function (?)
> - Context entry (?) [^error.log] [^save-context.webm]
> - Invocation (?)
> h3. Kogito (/)
> - Decision node
> - BKM node
> - Cleared Function
> - Context entry
> - Invocation
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (JGRP-2422) Log protocols per class
by Diego Lovison (Jira)
Diego Lovison created JGRP-2422:
-----------------------------------
Summary: Log protocols per class
Key: JGRP-2422
URL: https://issues.jboss.org/browse/JGRP-2422
Project: JGroups
Issue Type: Enhancement
Affects Versions: 4.1.8
Reporter: Diego Lovison
Assignee: Bela Ban
As a developer I would like to configure the protocols logs per class name
{noformat}
org.jgroups.protocols.MERGE3=TRACE
org.jgroups.protocols.FD_ALL=TRACE
org.jgroups.protocols.VERIFY_SUSPECT=TRACE
org.jgroups=DEBUG
{noformat}
All class will be using DEBUG except MERGE3, FD_ALL and VERIFY_SUSPECT that will be using TRACE
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (JGRP-2422) Log protocols per class
by Diego Lovison (Jira)
[ https://issues.jboss.org/browse/JGRP-2422?page=com.atlassian.jira.plugin.... ]
Diego Lovison reassigned JGRP-2422:
-----------------------------------
Assignee: Diego Lovison (was: Bela Ban)
> Log protocols per class
> -----------------------
>
> Key: JGRP-2422
> URL: https://issues.jboss.org/browse/JGRP-2422
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 4.1.8
> Reporter: Diego Lovison
> Assignee: Diego Lovison
> Priority: Critical
>
> As a developer I would like to configure the protocols logs per class name
> {noformat}
> org.jgroups.protocols.MERGE3=TRACE
> org.jgroups.protocols.FD_ALL=TRACE
> org.jgroups.protocols.VERIFY_SUSPECT=TRACE
> org.jgroups=DEBUG
> {noformat}
> All class will be using DEBUG except MERGE3, FD_ALL and VERIFY_SUSPECT that will be using TRACE
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times
by Martin Svehla (Jira)
[ https://issues.jboss.org/browse/WFWIP-276?page=com.atlassian.jira.plugin.... ]
Martin Svehla commented on WFWIP-276:
-------------------------------------
[~jdenise] you wrote in one of the previous comments that we need analysis of the solution. I think that having some kind of description of the fix and figuring out all its impacts is argument for making this into RFE. It's up to us how much we document for the end users, but it doesn't sound as just an "implementation detail".
> Boot time of application built via S2I is much longer than in before-Galleon times
> ----------------------------------------------------------------------------------
>
> Key: WFWIP-276
> URL: https://issues.jboss.org/browse/WFWIP-276
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Jan Blizňák
> Assignee: Jean Francois Denise
> Priority: Critical
> Attachments: test-app.zip
>
>
> As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration.
> This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc):
> ||17.0-6||pod time||EAP boot||config time
> |#1 | 8283|6128|2155
> |#2 | 9446|7548|1898
> |#3 | 8767|6871| 1896
> |#4 | 8568|6272| 2296
> |#5 | 8000 |6362|1638
> ||average ||8613ms||6636ms||1977ms
> ||18.0-7||pod time||EAP boot||config time
> |#1 |13769|5716|8053
> |#2 |13362|5952|7410
> |#3 |14261|6093|8168
> |#4 |14322|6135|8187
> |#5 |13921|6326|7595
> ||average||13927ms||6044ms||7883ms
> pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}})
> EAP boot = time of boot EAP itself == {{started in ..}}
> config time = the difference of previou timess = anything before EAP boot begins
> Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images.
> This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime.
> The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (DROOLS-4767) Fix error-popover position on simulation/background grids
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-4767?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi updated DROOLS-4767:
-------------------------------------
Description:
When there is only one column on the grid, the popover is show to the left. But if there is not enough space to the left, the popover is not visible.
Proposed solution, for this situation, is to show the popover _above_ the cell.
The final position preference order will be (respect the cell):
RIGHT -> LEFT -> ABOVE
was:
When there is only one column on the grid, the popover is show to the left. But if there is not enough space to the left, the popover is not visible.
Proposed solution, for this situation, is to show the popover _below_ the cell.
If there is not space below, the the popover will be shown _above_.
The final position preference order will be (respect the cell):
RIGTH -> LEFT -> BELOW -> ABOVE
> Fix error-popover position on simulation/background grids
> ---------------------------------------------------------
>
> Key: DROOLS-4767
> URL: https://issues.jboss.org/browse/DROOLS-4767
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
>
> When there is only one column on the grid, the popover is show to the left. But if there is not enough space to the left, the popover is not visible.
> Proposed solution, for this situation, is to show the popover _above_ the cell.
> The final position preference order will be (respect the cell):
> RIGHT -> LEFT -> ABOVE
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months