[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Matteo Mortari (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-4724:
----------------------------------------
And to avoid misunderstandings, either:
null
Or
null // comment ...
I have added quotes in my prev comment to mark start end of the feel expr.
> [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, 4 months
[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Matteo Mortari (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-4724:
----------------------------------------
Hi, my advice for the case of context entry was to _not_ leave the expression text empty, but have it as "null" or even better as "null // comment ..." see my comment above. It was replied this will have been done directly by the f/e code. By the look at the screenshot it appears this is not the case, yet. Are we sure this is implemented by the code? If so, can you point me to where this is done so I can check if something else is affecting the intended behavior? Hope this helps
> [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, 4 months
[JBoss JIRA] (DROOLS-4724) [DMN Designer] Do not default to a LiteralExpression when no expression is defined
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-4724?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-4724:
----------------------------------------
[~tari_manga] Waiting on your advice please.
> [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, 4 months
[JBoss JIRA] (DROOLS-4828) [DMN Designer] The tab in Data Type constraints while adding Enumeration goes to wrong icon
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-4828?page=com.atlassian.jira.plugi... ]
Michael Anstis reassigned DROOLS-4828:
--------------------------------------
Assignee: karreiro (was: Michael Anstis)
> [DMN Designer] The tab in Data Type constraints while adding Enumeration goes to wrong icon
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-4828
> URL: https://issues.jboss.org/browse/DROOLS-4828
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Daniel José dos Santos
> Assignee: karreiro
> Priority: Minor
> Labels: drools-tools
>
> 1. In the Data Type constraints modal, when adding "Enumeration", after the string is typed if user press "Tab" the focus goes to the cancel button (the X) instead of the "V" button (the apply).
> 2. I think is not clear how to apply with keyboard shortcut. In the Data Type tab, CTRL + S saves, but in this modal CTRL + S calls the default browser behavior. I think it have to be consistent.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFLY-12836) Large allocations in EJBContextImpl#isCallerInRole
by Philippe Marschall (Jira)
[ https://issues.jboss.org/browse/WFLY-12836?page=com.atlassian.jira.plugin... ]
Philippe Marschall updated WFLY-12836:
--------------------------------------
Description:
In our application we have the need to know the roles of the current user. We would like to do this using Java / Jakarta EE APIs rather than rely on WildFly implementation classes. We do this by iterating over all roles, which we know statically, and calling {{EJBContext#isCallerInRole}} for each one. This seem to be a common technique, see [How to get user roles in a JSP / Servlet|https://stackoverflow.com/questions/344117/how-to-get-user-roles-...].
That's about 100 roles for us. We were expecting that would be a lookup into a {{HashMap}} or similar with O(1) complexity and almost no allocations.
This however does not seem to be case as {{EJBContextImpl#isCallerInRole}} seems to do the role mapping for every call. This results in a large amount of allocations. In our case this completely dominates our allocation profile. See attached screenshot from JFR.
was:
In our application we have the need to know the roles of the current user. We would like to do this using Java / Jakarta EE APIs rather than rely on WildFly implementation classes. We do this by iterating over all roles, which we know statically, and calling {{EJBContext#isCallerInRole}} for each one. This seem to be a common technique, see [How to get user roles in a JSP / Servlet](https://stackoverflow.com/questions/344117/how-to-get-user-roles....
That's about 100 roles for us. We were expecting that would be a lookup into a {{HashMap}} or similar with O(1) complexity and almost no allocations.
This however does not seem to be case as {{EJBContextImpl#isCallerInRole}} seems to do the role mapping for every call. This results in a large amount of allocations. In our case this completely dominates our allocation profile. See attached screenshot from JFR.
> Large allocations in EJBContextImpl#isCallerInRole
> --------------------------------------------------
>
> Key: WFLY-12836
> URL: https://issues.jboss.org/browse/WFLY-12836
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 18.0.1.Final
> Reporter: Philippe Marschall
> Assignee: Cheng Fang
> Priority: Major
> Attachments: elytron_allocations_redacted.PNG
>
>
> In our application we have the need to know the roles of the current user. We would like to do this using Java / Jakarta EE APIs rather than rely on WildFly implementation classes. We do this by iterating over all roles, which we know statically, and calling {{EJBContext#isCallerInRole}} for each one. This seem to be a common technique, see [How to get user roles in a JSP / Servlet|https://stackoverflow.com/questions/344117/how-to-get-user-roles-...].
> That's about 100 roles for us. We were expecting that would be a lookup into a {{HashMap}} or similar with O(1) complexity and almost no allocations.
> This however does not seem to be case as {{EJBContextImpl#isCallerInRole}} seems to do the role mapping for every call. This results in a large amount of allocations. In our case this completely dominates our allocation profile. See attached screenshot from JFR.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFLY-12836) Large allocations in EJBContextImpl#isCallerInRole
by Philippe Marschall (Jira)
Philippe Marschall created WFLY-12836:
-----------------------------------------
Summary: Large allocations in EJBContextImpl#isCallerInRole
Key: WFLY-12836
URL: https://issues.jboss.org/browse/WFLY-12836
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 18.0.1.Final
Reporter: Philippe Marschall
Assignee: Cheng Fang
Attachments: elytron_allocations_redacted.PNG
In our application we have the need to know the roles of the current user. We would like to do this using Java / Jakarta EE APIs rather than rely on WildFly implementation classes. We do this by iterating over all roles, which we know statically, and calling {{EJBContext#isCallerInRole}} for each one. This seem to be a common technique, see [How to get user roles in a JSP / Servlet](https://stackoverflow.com/questions/344117/how-to-get-user-roles....
That's about 100 roles for us. We were expecting that would be a lookup into a {{HashMap}} or similar with O(1) complexity and almost no allocations.
This however does not seem to be case as {{EJBContextImpl#isCallerInRole}} seems to do the role mapping for every call. This results in a large amount of allocations. In our case this completely dominates our allocation profile. See attached screenshot from JFR.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFCORE-4766) Add additional logging to ManagementInterfaceAddStepHandler.LenientVerifyInstallationStep
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-4766?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-4766:
-------------------------------------
Fix Version/s: 11.0.0.Beta4
> Add additional logging to ManagementInterfaceAddStepHandler.LenientVerifyInstallationStep
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-4766
> URL: https://issues.jboss.org/browse/WFCORE-4766
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 11.0.0.Beta3
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 11.0.0.Beta4
>
>
> Debugging a recent issue the class org.jboss.as.controller.management.ManagementInterfaceAddStepHandler.LenientVerifyInstallationStep was detecting missing services but was not logging anything despite this class making the decision to abort the start up of the server.
> If a handler is going to make such a terminal decision it should be logging why it is doing it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFCORE-4766) Add additional logging to ManagementInterfaceAddStepHandler.LenientVerifyInstallationStep
by Darran Lofthouse (Jira)
Darran Lofthouse created WFCORE-4766:
----------------------------------------
Summary: Add additional logging to ManagementInterfaceAddStepHandler.LenientVerifyInstallationStep
Key: WFCORE-4766
URL: https://issues.jboss.org/browse/WFCORE-4766
Project: WildFly Core
Issue Type: Bug
Components: Management
Affects Versions: 11.0.0.Beta3
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Debugging a recent issue the class org.jboss.as.controller.management.ManagementInterfaceAddStepHandler.LenientVerifyInstallationStep was detecting missing services but was not logging anything despite this class making the decision to abort the start up of the server.
If a handler is going to make such a terminal decision it should be logging why it is doing it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months