[JBoss JIRA] (WFCORE-4249) WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-4249?page=com.atlassian.jira.plugi... ]
Jeff Mesnil resolved WFCORE-4249.
---------------------------------
Fix Version/s: 8.0.0.Beta1
Resolution: Done
> WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups
> -----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4249
> URL: https://issues.jboss.org/browse/WFCORE-4249
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Lin Gao
> Assignee: Bartosz Baranowski
> Priority: Major
> Labels: downstream_dependency
> Fix For: 8.0.0.Beta1
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups
> Using WildFlyInitialContextFactory and calling a remote EJB server.
> Observations:
> 1) If the ejb lookup is "reproducer/TestSLSB!test.Test" (basically like a RemoteNaming lookup), the ejb is invoked successfully, but the caller is seen as anonymous instead of the ejbuser which is specified in the Context properties.
> Using the ejb-client type lookup: ejb:/reproducer/TestSLSB!test.Test , then it shows up as ejbuser as expected
> 2) if a client creates 2 InitialContexts and uses the lookup reproducer/TestSLSB!test.Test" on ctx1 , then uses the lookup "ejb:/reproducer/TestSLSB!test.Test " on ctx2 in that order, then they both show anonymous (as if it uses only the context that was created first).
> If you switch the order, and use ejb:/reproducer/TestSLSB!test.Test first, then they both show ejbuser
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFCORE-4249) WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-4249?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-4249:
--------------------------------
Git Pull Request: (was: https://github.com/wildfly/wildfly-core/pull/3612)
> WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups
> -----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4249
> URL: https://issues.jboss.org/browse/WFCORE-4249
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Lin Gao
> Assignee: Bartosz Baranowski
> Priority: Major
> Labels: downstream_dependency
> Fix For: 8.0.0.Beta1
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups
> Using WildFlyInitialContextFactory and calling a remote EJB server.
> Observations:
> 1) If the ejb lookup is "reproducer/TestSLSB!test.Test" (basically like a RemoteNaming lookup), the ejb is invoked successfully, but the caller is seen as anonymous instead of the ejbuser which is specified in the Context properties.
> Using the ejb-client type lookup: ejb:/reproducer/TestSLSB!test.Test , then it shows up as ejbuser as expected
> 2) if a client creates 2 InitialContexts and uses the lookup reproducer/TestSLSB!test.Test" on ctx1 , then uses the lookup "ejb:/reproducer/TestSLSB!test.Test " on ctx2 in that order, then they both show anonymous (as if it uses only the context that was created first).
> If you switch the order, and use ejb:/reproducer/TestSLSB!test.Test first, then they both show ejbuser
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11482) WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups
by Jeff Mesnil (Jira)
Jeff Mesnil created WFLY-11482:
----------------------------------
Summary: WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups
Key: WFLY-11482
URL: https://issues.jboss.org/browse/WFLY-11482
Project: WildFly
Issue Type: Bug
Components: Remoting
Reporter: Lin Gao
Assignee: Bartosz Baranowski
WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups
Using WildFlyInitialContextFactory and calling a remote EJB server.
Observations:
1) If the ejb lookup is "reproducer/TestSLSB!test.Test" (basically like a RemoteNaming lookup), the ejb is invoked successfully, but the caller is seen as anonymous instead of the ejbuser which is specified in the Context properties.
Using the ejb-client type lookup: ejb:/reproducer/TestSLSB!test.Test , then it shows up as ejbuser as expected
2) if a client creates 2 InitialContexts and uses the lookup reproducer/TestSLSB!test.Test" on ctx1 , then uses the lookup "ejb:/reproducer/TestSLSB!test.Test " on ctx2 in that order, then they both show anonymous (as if it uses only the context that was created first).
If you switch the order, and use ejb:/reproducer/TestSLSB!test.Test first, then they both show ejbuser
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3393) Please review scenario error cell text for legibility/accessibility.
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3393?page=com.atlassian.jira.plugi... ]
Klara Kufova commented on DROOLS-3393:
--------------------------------------
[~uxdlc], I agree. Let's change the font color and get rid of the bold font.
Regarding the cell grid lines; this is an implementation issue [~danielezonca] is dealing with; the fix is not that trivial, but there's a Jira opened (DROOLS-3191). It's definitely on our radar. :-)
> Please review scenario error cell text for legibility/accessibility.
> ---------------------------------------------------------------------
>
> Key: DROOLS-3393
> URL: https://issues.jboss.org/browse/DROOLS-3393
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Klara Kufova
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2018-11-30 at 11.59.32 AM.png, Screen Shot 2018-11-30 at 12.05.50 PM.png, Screen Shot 2018-12-04 at 9.08.37 AM.png, Screenshot from 2018-11-30 17-11-43.png
>
>
> [~kkufova] [~bdellasc]
> I noticed that the error text is a little "fuzzy" looking, the edges aren't very sharp and I was concerned that it might not be legible. I asked Danielle about the specs for it and it's the same size just bolded.
> I did an online accessibility text using the following tool, with our current hex values: https://webaim.org/resources/contrastchecker/. It failed for level 3 compliance, but I'm not sure we need to shoot for that or not? I tried the darker PatternFly red color "#8b0000" and it passed at all levels, even at smaller sizes.
> I'm wondering if we could use the darker red, in the non-bolded font? And if so, perhaps the text would be a little bit more legible.
> Just wanted to ask about this, please let me know what you think.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3412) Performance degradation with session pools
by Christian Liebhardt (Jira)
[ https://issues.jboss.org/browse/DROOLS-3412?page=com.atlassian.jira.plugi... ]
Christian Liebhardt commented on DROOLS-3412:
---------------------------------------------
Hi, the comment regarding "Skip dispose" was referring to the dispose implementation of StatefulKnowledgeSessionImpl itself (and not to our code), which takes a different path for session pools than it would for "normal" sessions.
I will check the globals and insertion of objects to see if it makes a difference and will try to capture the behavior in a benchmark.
> Performance degradation with session pools
> ------------------------------------------
>
> Key: DROOLS-3412
> URL: https://issues.jboss.org/browse/DROOLS-3412
> Project: Drools
> Issue Type: Bug
> Reporter: Christian Liebhardt
> Assignee: Mario Fusco
> Priority: Major
> Attachments: gc.png
>
>
> Hello,
> We've today updates to Drools 7.15 and as discussed with DROOLS-3228 we changed our code from calling _StatefulKnowledgeSessionImpl.reset_ ourselves to _KieSessionsPool_. However we then recognized that our application quickly became slower and slower over time (roughly after a few minutes of uptime, or a couple of hundred session create/dispose cycles).
> I haven't yet found the reason what is causing the slow down. However I think there is a difference in how we reset our sessions before session pools and how session pools do it. Perhaps that is a lead.
> *What we did*
> # Create a session
> # Use the session
> # Dispose and reset the session and go back to 2 for the next facts
> *What happens with session pools*
> # Create a session
> # Use the session
> # Skip dispose (because of _pool != null_ in the dispose method), reset the session and go back to 2 for the next facts
> So the difference seems to be that with session pools the session doesn't get disposed before reset it called. If I do the same without session pools then I also see the same slow down. So it seems that something is left behind and causes a slow down. The results however seem to be correct, so the right consequences appear to be triggered.
> An example on how we use the session pool can be found here: https://github.com/liebharc/JavaRules/blob/master/src/main/java/com/githu...
> Thanks once more for your help.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3234) Add a Donut widget to improve the visualisation of test report screen
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3234?page=com.atlassian.jira.plugi... ]
Klara Kufova edited comment on DROOLS-3234 at 12/6/18 6:53 AM:
---------------------------------------------------------------
[~uxdlc], the PR we're currently waiting for is [here|https://github.com/kiegroup/appformer/pull/506]. There is a number of pictures and videos linked (in [this|https://github.com/kiegroup/appformer/pull/506#issuecomment-444483417] comment). Could you please take a look at them? After it is merged, our chart will look quite similar to the one you just posted. Thank you for your suggestions, I agree with all of them; I think the best thing right now would be to wait for the !506 PR to be merged and then revise our chart again. Do you agree? You wouldn't have to do any other proposals, we can just compare the chart with what we already have here and decide how we will proceed.
I already asked both the development and QE teams to review the !506 PR, so hopefully it will be merged soon.
[~Rikkola], should we merge our PR now or should we wait for [!506|https://github.com/kiegroup/appformer/pull/506] to be merged first? What do you think?
was (Author: kkufova):
[~uxdlc], the PR we're currently waiting for is [here|https://github.com/kiegroup/appformer/pull/506]. There is a number of pictures and videos linked (in [this|https://github.com/kiegroup/appformer/pull/506#issuecomment-444483417] comment). Could you please take a look at them? After it is merged, our chart will look quite similar to the one you just posted. Thank you for your suggestions, I agree with all of them; I think the best thing right now would be to wait for the !506 PR to be merged and then revise our chart again. Do you agree? You wouldn't have to do any other proposals, we can just compare the chart with what we already have here.
I already asked both the development and QE teams to review the !506 PR, so hopefully it will be merged soon.
[~Rikkola], should we merge our PR now or should we wait for [!506|https://github.com/kiegroup/appformer/pull/506] to be merged first? What do you think?
> Add a Donut widget to improve the visualisation of test report screen
> ---------------------------------------------------------------------
>
> Key: DROOLS-3234
> URL: https://issues.jboss.org/browse/DROOLS-3234
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing, Test Scenarios Editor
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Priority: Major
> Attachments: donut.png, pie2b.png, screencast-04-12-18.webm
>
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3234) Add a Donut widget to improve the visualisation of test report screen
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3234?page=com.atlassian.jira.plugi... ]
Klara Kufova commented on DROOLS-3234:
--------------------------------------
[~uxdlc], the PR we're currently waiting for is [here|https://github.com/kiegroup/appformer/pull/506]. There is a number of pictures and videos linked (in [this|https://github.com/kiegroup/appformer/pull/506#issuecomment-444483417] comment). Could you please take a look at them? After it is merged, our chart will look quite similar to the one you just posted. Thank you for your suggestions, I agree with all of them; I think the best thing right now would be to wait for the !506 PR to be merged and then revise our chart again. Do you agree? You wouldn't have to do any other proposals, we can just compare the chart with what we already have here.
I already asked both the development and QE teams to review the !506 PR, so hopefully it will be merged soon.
[~Rikkola], should we merge our PR now or should we wait for [!506|https://github.com/kiegroup/appformer/pull/506] to be merged first? What do you think?
> Add a Donut widget to improve the visualisation of test report screen
> ---------------------------------------------------------------------
>
> Key: DROOLS-3234
> URL: https://issues.jboss.org/browse/DROOLS-3234
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing, Test Scenarios Editor
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Priority: Major
> Attachments: donut.png, pie2b.png, screencast-04-12-18.webm
>
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3286) [DMN Designer] FunctionGrid: Move F, J, P selector to header
by Daniel José dos Santos (Jira)
[ https://issues.jboss.org/browse/DROOLS-3286?page=com.atlassian.jira.plugi... ]
Daniel José dos Santos updated DROOLS-3286:
-------------------------------------------
Description:
The {{FunctionGrid}} allows switching between FEEL, Java and PMML function definitions using the context menu. [~tirelli] has requested this be changed to a selector in the header. A new column needs to be added with the F, J, P selector in the new column header. The header should display F, J or P accordingly. Do not include row numbers (i.e. don't just add a {{RowNumberColumn}}!
Also, the default in classes should be String, not Undefined.
was:The {{FunctionGrid}} allows switching between FEEL, Java and PMML function definitions using the context menu. [~tirelli] has requested this be changed to a selector in the header. A new column needs to be added with the F, J, P selector in the new column header. The header should display F, J or P accordingly. Do not include row numbers (i.e. don't just add a {{RowNumberColumn}}!
> [DMN Designer] FunctionGrid: Move F, J, P selector to header
> -------------------------------------------------------------
>
> Key: DROOLS-3286
> URL: https://issues.jboss.org/browse/DROOLS-3286
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Michael Anstis
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
>
> The {{FunctionGrid}} allows switching between FEEL, Java and PMML function definitions using the context menu. [~tirelli] has requested this be changed to a selector in the header. A new column needs to be added with the F, J, P selector in the new column header. The header should display F, J or P accordingly. Do not include row numbers (i.e. don't just add a {{RowNumberColumn}}!
> Also, the default in classes should be String, not Undefined.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3412) Performance degradation with session pools
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-3412?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-3412:
-------------------------------------
We have some jmh benchmarks for the sesssion pool and we didn't find any similar performance issue. See https://github.com/kiegroup/kie-benchmarks/tree/7f60e47cba510214cb86cb4bc... It would be great if you could provide some similar benchmark to demonstrate the problem that you're reporting.
Also I'm a bit confused about your description because you wrote
"Skip dispose (because of pool != null in the dispose method), reset the session and go back to 2 for the next facts"
but in the code you linked you're actually calling the dispose, which by the way is the correct thing to do because in that case it puts the session back into the pool.
Finally, looking at your code, it is also possible that you could have a memory leak on your side, because you are setting the same global and inserting the same dataStore instance into each session. However I cannot be sure of this, so my suggestion is to provide a jmh based benchmark (using your rules and domain classes if necessary) reproducing this performance problem, so we could investigate it further.
> Performance degradation with session pools
> ------------------------------------------
>
> Key: DROOLS-3412
> URL: https://issues.jboss.org/browse/DROOLS-3412
> Project: Drools
> Issue Type: Bug
> Reporter: Christian Liebhardt
> Assignee: Mario Fusco
> Priority: Major
> Attachments: gc.png
>
>
> Hello,
> We've today updates to Drools 7.15 and as discussed with DROOLS-3228 we changed our code from calling _StatefulKnowledgeSessionImpl.reset_ ourselves to _KieSessionsPool_. However we then recognized that our application quickly became slower and slower over time (roughly after a few minutes of uptime, or a couple of hundred session create/dispose cycles).
> I haven't yet found the reason what is causing the slow down. However I think there is a difference in how we reset our sessions before session pools and how session pools do it. Perhaps that is a lead.
> *What we did*
> # Create a session
> # Use the session
> # Dispose and reset the session and go back to 2 for the next facts
> *What happens with session pools*
> # Create a session
> # Use the session
> # Skip dispose (because of _pool != null_ in the dispose method), reset the session and go back to 2 for the next facts
> So the difference seems to be that with session pools the session doesn't get disposed before reset it called. If I do the same without session pools then I also see the same slow down. So it seems that something is left behind and causes a slow down. The results however seem to be correct, so the right consequences appear to be triggered.
> An example on how we use the session pool can be found here: https://github.com/liebharc/JavaRules/blob/master/src/main/java/com/githu...
> Thanks once more for your help.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months