March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6367) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/AS7-6367?page=com.atlassian.jira.plugin.s... ] jaikiran pai commented on AS7-6367: ----------------------------------- Philippe, please create a forum thread with relevant details so that we can discuss there. I'll update this JIRA with the status update on where this currently stands. > Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms > ------------------------------------------------------------------------------------------------------------ > > Key: AS7-6367 > URL: https://issues.jboss.org/browse/AS7-6367 > Project: Application Server 7 > Issue Type: Bug > Components: EJB > Affects Versions: 7.1.3.Final (EAP) > Reporter: Derek Horton > Assignee: jaikiran pai > > My confusion is around the remoting/security-realm setup in the use case > where multiple EJBs are deployed that use different security-domains and > the EJBs will be invoked by remote standalone clients. For example, > ejbX needs to be in the sec-domain-X security-domain, while ejbY needs to > be in the sec-domain-Y security-domain. > In this situation, the authentication checks are going to be handled by > the security-realm that is associated with the remote connector that is > configured to be used by the EJB subsystem. > It looks like the security-realm can either handle the authentication > checks directly (properties file, ldap, etc) or it can defer to the > jaas security-domain. In both of those situations, it seems that the > EJBs are limited to a single authentication point. The EJB > authentication is either going to be handled by a single security-realm > or the security-realm will defer to a single security-domain. > I could configure the security-domain to have multiple login modules. I > assume the same thing could be done with the security-realm. > Basically the problem that I am trying to solve boils down to this: the > authentication checks for remote EJBs appear to be checked by either a > single security-realm or a single security-domain. Is there a way to > change this? > One idea I had was to add another remote connector to the EJB subsystem. > Unfortunately, this does not appear to be possible. -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1544) FORWARD_TO_COORD is slow

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1544?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1544. ---------------------------- Resolution: Done Backported to 3.2.8 > FORWARD_TO_COORD is slow > ------------------------ > > Key: JGRP-1544 > URL: https://issues.jboss.org/browse/JGRP-1544 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.2.8, 3.3 > > > When doing xsite perf tests, JGRP-1542 fixed a perf issue by passing message flags on when forwarding / relaying a message. However, the biggest perf culprit was FORWARD_TO_COORD. > This JIRA will investigate the cause (probably the forward-table and delivery-table handling) and hopefully fix it. > Meanwhile, the recommendadtion is to comment FORWARD_TO_COORD. -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1544) FORWARD_TO_COORD is slow

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1544?page=com.atlassian.jira.plugin.... ] Bela Ban reopened JGRP-1544: ---------------------------- Backport to 3.2.x branch > FORWARD_TO_COORD is slow > ------------------------ > > Key: JGRP-1544 > URL: https://issues.jboss.org/browse/JGRP-1544 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > > When doing xsite perf tests, JGRP-1542 fixed a perf issue by passing message flags on when forwarding / relaying a message. However, the biggest perf culprit was FORWARD_TO_COORD. > This JIRA will investigate the cause (probably the forward-table and delivery-table handling) and hopefully fix it. > Meanwhile, the recommendadtion is to comment FORWARD_TO_COORD. -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1544) FORWARD_TO_COORD is slow

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1544?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1544: --------------------------- Fix Version/s: 3.2.8 > FORWARD_TO_COORD is slow > ------------------------ > > Key: JGRP-1544 > URL: https://issues.jboss.org/browse/JGRP-1544 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.2.8, 3.3 > > > When doing xsite perf tests, JGRP-1542 fixed a perf issue by passing message flags on when forwarding / relaying a message. However, the biggest perf culprit was FORWARD_TO_COORD. > This JIRA will investigate the cause (probably the forward-table and delivery-table handling) and hopefully fix it. > Meanwhile, the recommendadtion is to comment FORWARD_TO_COORD. -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-122) Concurrency Utilities for Java EE (JSR-236)

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/JBEE-122?page=com.atlassian.jira.plugin.s... ] Shelly McGowan commented on JBEE-122: ------------------------------------- More diffs detected. Pull request sent: https://github.com/jboss/jboss-javaee-concurrency-api_spec/pull/1 > Concurrency Utilities for Java EE (JSR-236) > -------------------------------------------- > > Key: JBEE-122 > URL: https://issues.jboss.org/browse/JBEE-122 > Project: JBoss JavaEE Spec APIs > Issue Type: Sub-task > Components: jboss-javaee-concurrency-api > Reporter: Shelly McGowan > Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1 > > > These APIs are required as part of our Java EE 7 implementation. > They should be added to the org.jboss.spec project: > {code} > <dependency> > <groupId>org.jboss.spec.javax.enterprise.concurrent</groupId> > <artifactId>jboss-concurrent-api_1.0_spec</artifactId> > <version>1.0.0.Final-SNAPSHOT</version> > </dependency> > {code} > Project can be created in http://github.com/jboss/jboss-concurrent-api_spec -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1006) isSameRmOverride doesn't take effect

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1006?page=com.atlassian.jira.plugin... ] Jesper Pedersen commented on JBJCA-1006: ---------------------------------------- If <is-same-rm-override> is defined with any value, then <wrap-xa-resource>true</wrap-xa-resource> needs to be specified > isSameRmOverride doesn't take effect > ------------------------------------ > > Key: JBJCA-1006 > URL: https://issues.jboss.org/browse/JBJCA-1006 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.15.Final, 1.1.0.Beta4 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Blocker > Fix For: 1.0.16.Final, 1.1.0.Beta5 > > -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1006) isSameRmOverride doesn't take effect

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1006?page=com.atlassian.jira.plugin... ] Jesper Pedersen updated JBJCA-1006: ----------------------------------- Workaround Description: <wrap-xa-resource>false</wrap-xa-resource> > isSameRmOverride doesn't take effect > ------------------------------------ > > Key: JBJCA-1006 > URL: https://issues.jboss.org/browse/JBJCA-1006 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.15.Final, 1.1.0.Beta4 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Blocker > Fix For: 1.0.16.Final, 1.1.0.Beta5 > > -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1006) isSameRmOverride doesn't take effect

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1006?page=com.atlassian.jira.plugin... ] Jesper Pedersen updated JBJCA-1006: ----------------------------------- Priority: Blocker (was: Critical) > isSameRmOverride doesn't take effect > ------------------------------------ > > Key: JBJCA-1006 > URL: https://issues.jboss.org/browse/JBJCA-1006 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.15.Final, 1.1.0.Beta4 > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Blocker > Fix For: 1.0.16.Final, 1.1.0.Beta5 > > -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1008) Assert.fail() cannot be surrounded with a try-catch block which catches a general Throwable

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1008?page=com.atlassian.jira.plugin... ] Ivo Studensky commented on JBJCA-1008: -------------------------------------- The committed change has been reverted. Attaching the patch to this jira. > Assert.fail() cannot be surrounded with a try-catch block which catches a general Throwable > ------------------------------------------------------------------------------------------- > > Key: JBJCA-1008 > URL: https://issues.jboss.org/browse/JBJCA-1008 > Project: IronJacamar > Issue Type: Bug > Components: Test suite > Affects Versions: 1.0.15.Final, 1.1.0.Beta4 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 1.0.16.Final, 1.1.0.Beta5 > > Attachments: JBJCA-1008.patch > > > In IJ test suite there are occurrences of Assert.fail(String) surrounding with a try-catch block that catches a general Throwable. This effectively means that AssertionError produced by Assert.fail() is eaten by the following catch clause, usually quietly. And then such a test passes instead of it fails. > Affected tests: > {noformat} > adapters/src/test/java/org/jboss/jca/adapters/jdbc/unit/H2SecurityDomainMultipleUsersTestCase.java > core/src/test/java/org/jboss/jca/core/connectionmanager/connections/InterleavingTestCase.java > deployers/src/test/java/org/jboss/jca/deployers/annotations/AnnotationsTestCase.java > embedded/src/test/java/org/jboss/jca/embedded/unit/ShrinkWrapTestCase.java > {noformat} -- 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

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1008) Assert.fail() cannot be surrounded with a try-catch block which catches a general Throwable

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1008?page=com.atlassian.jira.plugin... ] Ivo Studensky updated JBJCA-1008: --------------------------------- Attachment: JBJCA-1008.patch > Assert.fail() cannot be surrounded with a try-catch block which catches a general Throwable > ------------------------------------------------------------------------------------------- > > Key: JBJCA-1008 > URL: https://issues.jboss.org/browse/JBJCA-1008 > Project: IronJacamar > Issue Type: Bug > Components: Test suite > Affects Versions: 1.0.15.Final, 1.1.0.Beta4 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 1.0.16.Final, 1.1.0.Beta5 > > Attachments: JBJCA-1008.patch > > > In IJ test suite there are occurrences of Assert.fail(String) surrounding with a try-catch block that catches a general Throwable. This effectively means that AssertionError produced by Assert.fail() is eaten by the following catch clause, usually quietly. And then such a test passes instead of it fails. > Affected tests: > {noformat} > adapters/src/test/java/org/jboss/jca/adapters/jdbc/unit/H2SecurityDomainMultipleUsersTestCase.java > core/src/test/java/org/jboss/jca/core/connectionmanager/connections/InterleavingTestCase.java > deployers/src/test/java/org/jboss/jca/deployers/annotations/AnnotationsTestCase.java > embedded/src/test/java/org/jboss/jca/embedded/unit/ShrinkWrapTestCase.java > {noformat} -- 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

13 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2013