[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)
6 years
[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)
6 years
[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)
6 years
[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)
6 years
[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)
6 years