April 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3220) ARJUNA016009 ArrayIndexOutOfBoundsException during periodic recovery on EJBTransactionRecoveryService

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3220?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3220: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1035216|https://bugzilla.redhat.com/show_bug.cgi?id=1035216] from MODIFIED to ON_QA > ARJUNA016009 ArrayIndexOutOfBoundsException during periodic recovery on EJBTransactionRecoveryService > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-3220 > URL: https://issues.jboss.org/browse/WFLY-3220 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.Final > Reporter: Masafumi Miura > Assignee: Masafumi Miura > Fix For: 8.1.0.CR1 > > Attachments: WFLY-3220-byteman-script.btm > > > https://bugzilla.redhat.com/show_bug.cgi?id=1035216 is also reproducible in wildfly. > {code} > WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.ArrayIndexOutOfBoundsException: 0 > at org.jboss.as.ejb3.remote.EJBTransactionRecoveryService.getXAResources(EJBTransactionRecoveryService.java:114) > at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)] > {code} > I think the line 111 "new XAResource\[receiverContexts.size()\]" should be placed inside synchronized block. > {code:java|title=ejb3/src/main/java/org/jboss/as/ejb3/remote/EJBTransactionRecoveryService.java} > 109 @Override > 110 public XAResource[] getXAResources() { > 111 final XAResource[] xaResources = new XAResource[receiverContexts.size()]; > 112 synchronized (receiverContexts) { > 113 for (int i = 0; i < receiverContexts.size(); i++) { > 114 xaResources[i] = EJBClientManagedTransactionContext.getEJBXAResourceForRecovery(receiverContexts.get(i), arjunaTxCoreEnvironmentBean.getValue().getNodeIdentifier()); > 115 } > 116 } > 117 return xaResources; > 118 } > ... > 124 @Override > 125 public void receiverRegistered(final EJBReceiverContext receiverContext) { > 126 this.receiverContexts.add(receiverContext); > 127 } > {code} > I think this "java.lang.ArrayIndexOutOfBoundsException: 0" will happen in the following scenario: > # receiverContexts.size() = 0 at the line 111 > xaResources is created with new XAResource\[0\] > # receiverRegistered method is called from other thread between the line 111 and 112 > Now receiverContexts.size() = 1 > # As receiverContexts.size() = 1, for-loop is executed > Then "xaResources\[0\] = ..." will get ArrayIndexOutOfBoundsException at the line 114 because xaResources is empty array. -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2147) Improve RBAC Performance

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2147?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2147: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1077536|https://bugzilla.redhat.com/show_bug.cgi?id=1077536] from MODIFIED to ON_QA > Improve RBAC Performance > ------------------------ > > Key: WFLY-2147 > URL: https://issues.jboss.org/browse/WFLY-2147 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 9.0.0.CR1 > > > Parent task for work related to reducing the impact of RBAC (WFLY-490) on management operation performance. -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2623) Unable to change process-id mechanism from process-id-uuid to process-id-socket-binding on transaction

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2623?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2623: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1036739|https://bugzilla.redhat.com/show_bug.cgi?id=1036739] from MODIFIED to ON_QA > Unable to change process-id mechanism from process-id-uuid to process-id-socket-binding on transaction > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-2623 > URL: https://issues.jboss.org/browse/WFLY-2623 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transactions > Affects Versions: 8.0.0.Beta1 > Reporter: Amos Feng > Assignee: Hayk Hovsepyan > Labels: transaction > Fix For: 8.0.0.Final > > > https://bugzilla.redhat.com/show_bug.cgi?id=1036739 > process-id mechanism can not be changed from process-id-uuid to process-id-socket-binding. > The following ERROR occurred at JBoss start-up: > {noformat} > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 44) JBAS014613: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: "JBAS014746: process-id-uuid may not be null" > {noformat} > The root reason is it does not check the PROCESS_ID_UUID if defined when booting the coreEnvironment service in TransactionSubsytemAdd. -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3228) ApplyRemoteMasterDomainHandler should use values sent from DC for root resource

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3228?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3228: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1085122|https://bugzilla.redhat.com/show_bug.cgi?id=1085122] from MODIFIED to ON_QA > ApplyRemoteMasterDomainHandler should use values sent from DC for root resource > ------------------------------------------------------------------------------- > > Key: WFLY-3228 > URL: https://issues.jboss.org/browse/WFLY-3228 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 8.1.0.CR1 > > > This is needed to keep the slave copy of the resource model actually the same, and popped up during mixed domain testing of EAP with a 6.2.0 slave. > Connect directly to to 6.1.1 slave - gets domain version from master > {code} > [domain@localhost:19999 /] :read-resource > { > "outcome" => "success", > "result" => { > "deployment" => undefined, > "deployment-overlay" => undefined, > "management-major-version" => 1, > "management-micro-version" => 0, > "management-minor-version" => 6, > "name" => "Unnamed Domain", > "namespaces" => [], > "path" => undefined, > "product-name" => "EAP", > "product-version" => "6.3.0.Alpha3", > "profile" => undefined, > "release-codename" => "Janus", > "release-version" => "7.4.0.Final-redhat-SNAPSHOT", > {code} > Connect directly to 6.2.0 slave - does not get domain version from master > {code} > [domain@localhost:19999 /] :read-resource > { > "outcome" => "success", > "result" => { > "management-major-version" => 1, > "management-micro-version" => 0, > "management-minor-version" => 5, > "name" => "Unnamed Domain", > "namespaces" => [], > "product-name" => "EAP", > "product-version" => "6.2.0.GA", > "release-codename" => "Janus", > "release-version" => "7.3.0.Final-redhat-14", > {code} > The 6.2.0 slave should look the same as the 6.1.1 slave for these attributes. -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3048: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1043667|https://bugzilla.redhat.com/show_bug.cgi?id=1043667] from MODIFIED to ON_QA > "Local" authentication fails when LDAP is used for ManagementRealm > ------------------------------------------------------------------ > > Key: WFLY-3048 > URL: https://issues.jboss.org/browse/WFLY-3048 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.Final > Environment: Ubuntu 13.04, Xeon-based VPS > Reporter: Matt Jensen > Assignee: Darran Lofthouse > Fix For: 8.1.0.CR1 > > > When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working. > I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows: > <security-realm name="ManagementRealm"> > <authentication> > <local default-user="$local" /> > <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false"> > ... > </ldap> > </authentication> > <authorization map-groups-to-roles="false"> > <ldap connection="..."> > ... > </ldap> > </authorization> > </security-realm> > I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command. > The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm. > If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password. > I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password. > The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up. > The documentation specifically mentions that <local/> should work along with <ldap/> here: > https://docs.jboss.org/author/display/WFLY8/Security+Realms -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3053) BootstrapImpl#bootstrap result is inherently racy

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3053?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3053: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1071934|https://bugzilla.redhat.com/show_bug.cgi?id=1071934] from MODIFIED to ON_QA > BootstrapImpl#bootstrap result is inherently racy > ------------------------------------------------- > > Key: WFLY-3053 > URL: https://issues.jboss.org/browse/WFLY-3053 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Reporter: David Lloyd > Assignee: Richard Opalka > Fix For: 8.1.0.CR1 > > > The boostrap code presently installs a stability monitor and awaits stability before returning. It then probes the state of the root service. There is a window of time in which the root service may be stopped or removed, resulting in big exception traces being logged. To atomically get the result of the operation, the service container must somehow be frozen until the root service is completely read. -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3198) Reenabling an application prevents it from deployement after a restart

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3198?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3198: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1074999|https://bugzilla.redhat.com/show_bug.cgi?id=1074999] from MODIFIED to ON_QA > Reenabling an application prevents it from deployement after a restart > ---------------------------------------------------------------------- > > Key: WFLY-3198 > URL: https://issues.jboss.org/browse/WFLY-3198 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: ConfigAdmin > Affects Versions: 8.0.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Fix For: 8.1.0.CR1 > > > After disabling and then re-enabling the application, I don't see Application.war.deployed; I still see Application.war.undeployed. > That explains why it doesn't get deployed after restart. -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2906) WildFly 8.0.0 Final keeps lock on Manifest.mf files in exploded deployment

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2906?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2906: ----------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1085294|https://bugzilla.redhat.com/show_bug.cgi?id=1085294] from MODIFIED to ON_QA > WildFly 8.0.0 Final keeps lock on Manifest.mf files in exploded deployment > -------------------------------------------------------------------------- > > Key: WFLY-2906 > URL: https://issues.jboss.org/browse/WFLY-2906 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF, Web (Undertow) > Affects Versions: 8.0.0.Final > Environment: Windows7x64, Oracle Java 1.7.0_51 > Reporter: Wolfgang Knauf > Assignee: Tomaz Cerar > Fix For: 8.1.0.CR1 > > > I have a small JSF web app. When performing exploded deployment, after a ".dodeploy"/."undeploy"/".dodeploy"/".undeploy" cycle, the manifest.mf files are locked (I cannot delete the files, Windows tells me that they are used by a Java process) > A similar sample without JSF (and beans.xml) does not show this problem. > See the forum post for more details and the zip file of the "to be deployed" app. -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-815) NegotiationAuthenticator loses post data

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-815?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-815: -------------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1085497|https://bugzilla.redhat.com/show_bug.cgi?id=1085497] from MODIFIED to ON_QA > NegotiationAuthenticator loses post data > ---------------------------------------- > > Key: SECURITY-815 > URL: https://issues.jboss.org/browse/SECURITY-815 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_5 > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: Negotiation_2_3_0_CR2 > > > The NegotiationAuthenticator loses post data. > A customer is attempting to use Negotiation along with PicketLink at the IDP. This works fine as long as the SP is using HTTP-Redirect SAML binding. > If the SP is using HTTP-Redirect, then this issue is avoided as the SAMLRequest is passed along through the redirects on the URL. > If the HTTP-POST binding is used, then the NegotiationAuthenticator will lose the SAMLRequest post parameter. This means that after a user is successfully authenticated, the IDP will not know where to redirect the user to. As a result, the user will be left at the IDP index.html page. -- 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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-722) SPNEGO-fallback-to-FORM authentication does not work with httpd+JBossEAP6 if SPNEGO not available

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-722?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-722: -------------------------------------------------- Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1085497|https://bugzilla.redhat.com/show_bug.cgi?id=1085497] from MODIFIED to ON_QA > SPNEGO-fallback-to-FORM authentication does not work with httpd+JBossEAP6 if SPNEGO not available > ------------------------------------------------------------------------------------------------- > > Key: SECURITY-722 > URL: https://issues.jboss.org/browse/SECURITY-722 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Affects Versions: Negotiation_2_2_1 > Environment: RHEL6, JBoss EAP 6 > Reporter: flame liu > Assignee: Derek Horton > Fix For: Negotiation_2_3_0_CR2 > > > I configured SPNEGO in EAP6. It works well both with EAP only and EAP6 + Apache httpd(mod_proxy). Users just run kinit and will be able to be successfully authenticated. > After that, I added the fallback-to-form files/configurations both in the web app and standalone-full.xml. The fallback-to-form works only if httpd stops. If httpd starts, 401 error will always be thrown out. -- 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

12 years, 3 months

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 April 2014