October 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2216) include-all role mappings don't work in domain

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2216: ----------------------------------------------- Ladislav Thon <lthon(a)redhat.com> made a comment on [bug 1015493|https://bugzilla.redhat.com/show_bug.cgi?id=1015493] If I understand correctly, roles that have include-all=true in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode. In domain mode, if I set a role mapping to include-all, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be include-all -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on. The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the "RBAC tests for include-all role mappings in domain" commit). If it's more convenient, the pull request is the same as my rbac branch (https://github.com/Ladicek/wildfly/commits/rbac). This might be related to bug 1014271. > include-all role mappings don't work in domain > ---------------------------------------------- > > Key: WFLY-2216 > URL: https://issues.jboss.org/browse/WFLY-2216 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Ladislav Thon > Assignee: Darran Lofthouse > Labels: rbac-filed-by-qa > > If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode. > In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on. > The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac). > Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-285) JtaTransactionSynchronizationAdapter contains infite loop

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-285?page=com.atlassian.jira.plugin... ] Davide Sottara commented on DROOLS-285: --------------------------------------- Good catch! Patched > JtaTransactionSynchronizationAdapter contains infite loop > --------------------------------------------------------- > > Key: DROOLS-285 > URL: https://issues.jboss.org/browse/DROOLS-285 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Reporter: Nils Miehe > Assignee: Mark Proctor > Fix For: 6.0.0.CR5 > > > I stumbled upon this while searching for a potential cause of JBPM-4132 . > In the method afterCompletion of JtaTransactionSynchronizationAdapter a call with STATUS_ACTIVE would cause an infinite loop. As this value in itself indicates an inconsistent state the error probably wasn't noticed earlier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2216) include-all role mappings don't work in domain

by Ladislav Thon (JIRA)

Ladislav Thon created WFLY-2216: ----------------------------------- Summary: include-all role mappings don't work in domain Key: WFLY-2216 URL: https://issues.jboss.org/browse/WFLY-2216 Project: WildFly Issue Type: Bug Components: Domain Management, Security Reporter: Ladislav Thon Assignee: Darran Lofthouse If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode. In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on. The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac). Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2216) include-all role mappings don't work in domain

by Ladislav Thon (JIRA)

[ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.... ] Ladislav Thon updated WFLY-2216: -------------------------------- Parent: WFLY-490 Issue Type: Sub-task (was: Bug) > include-all role mappings don't work in domain > ---------------------------------------------- > > Key: WFLY-2216 > URL: https://issues.jboss.org/browse/WFLY-2216 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Ladislav Thon > Assignee: Darran Lofthouse > Labels: rbac-filed-by-qa > > If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode. > In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on. > The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac). > Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1714) Headers: data in some headers might be too large in big clusters

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1714?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1714 at 10/4/13 7:43 AM: --------------------------------------------------------- * {{PingHeader}}: DONE * {{FD_SOCK.FdHeader}}: DONE * {{STABLE.StableHeader}}: DONE * {{FLUSH.FlushHeader}}: DONE was (Author: belaban): * {{PingHeader}}: DONE * {{FD_SOCK.FdHeader}}: DONE * {{STABLE.StableHeader}}: DONE > Headers: data in some headers might be too large in big clusters > ---------------------------------------------------------------- > > Key: JGRP-1714 > URL: https://issues.jboss.org/browse/JGRP-1714 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4 > > > Similar to JGRP-1710 and JGRP-1713, investigate headers which might become too big, and move their contents into the message body. Check all headers which contain > * a view > * a digest > * a list of members > Candidates: > * {{PingHeader}}. > Probable solution: move {{PingHeader.PingData}} from the header to the message body -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the thread waiting

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1711?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1711: --------------------------- Fix Version/s: 3.5 (was: 3.4) > DELAY2: Do not keep the thread waiting > -------------------------------------- > > Key: JGRP-1711 > URL: https://issues.jboss.org/browse/JGRP-1711 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.4 > Reporter: Radim Vansa > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period. > As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period. > For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers. > Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-285) JtaTransactionSynchronizationAdapter contains infite loop

by Nils Miehe (JIRA)

Nils Miehe created DROOLS-285: --------------------------------- Summary: JtaTransactionSynchronizationAdapter contains infite loop Key: DROOLS-285 URL: https://issues.jboss.org/browse/DROOLS-285 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.5.0.Final Reporter: Nils Miehe Assignee: Mark Proctor Fix For: 6.0.0.CR5 I stumbled upon this while searching for a potential cause of JBPM-4132 . In the method afterCompletion of JtaTransactionSynchronizationAdapter a call with STATUS_ACTIVE would cause an infinite loop. As this value in itself indicates an inconsistent state the error probably wasn't noticed earlier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2215) WorkManagerService does not start work manager

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created WFLY-2215: ---------------------------------------- Summary: WorkManagerService does not start work manager Key: WFLY-2215 URL: https://issues.jboss.org/browse/WFLY-2215 Project: WildFly Issue Type: Enhancement Components: JCA Affects Versions: 8.0.0.Beta1 Reporter: Bartosz Baranowski Assignee: Stefano Maestri Fix For: 8.0.0.Beta1 WorkManagerService does not start/restart WorkManager https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/or... WorkManager is set in constructor. In stop method, WorkManager.shutdown() is called. start() should invoke WorkManager.cancelShutdown(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2181) TempFileProviderService creates a static, non-daemon thread pool

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2181?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2181: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> made a comment on [bug 1012968|https://bugzilla.redhat.com/show_bug.cgi?id=1012968] Verified on EAP 6.2.0.ER4 > TempFileProviderService creates a static, non-daemon thread pool > ---------------------------------------------------------------- > > Key: WFLY-2181 > URL: https://issues.jboss.org/browse/WFLY-2181 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 8.0.0.Alpha4 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 8.0.0.Beta1 > > > This can prevent the server from shutting down -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2181) TempFileProviderService creates a static, non-daemon thread pool

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2181?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2181: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1012968|https://bugzilla.redhat.com/show_bug.cgi?id=1012968] from ON_QA to VERIFIED > TempFileProviderService creates a static, non-daemon thread pool > ---------------------------------------------------------------- > > Key: WFLY-2181 > URL: https://issues.jboss.org/browse/WFLY-2181 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 8.0.0.Alpha4 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 8.0.0.Beta1 > > > This can prevent the server from shutting down -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 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 October 2013