Description of problem: Platform issue for GTNPORTAL-3572 MembershipDAOImpl.linkMembership(...) is missing exception handling around the following call: getIdentitySession().getRoleManager().createRole(mt.getName(), user.getUserName(), groupId); If this call fails, eg. for example due to an exception from the underlying database, this result in a corrupted transaction state. Subsequent requests using this thread fail with an error similar to the following: org.hibernate.AssertionFailure: null id in org.picketlink.idm.impl.model.hibernate.HibernateIdentityObjectRelationship entry (don't flush the Session after an exception occurs) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Steps to reproduce the error, and test a fix: 1. Start JPP 6 2. Login as root and create: - a new group /platform/test - a new user demo (only assigned to /platform/users) 3. Stop the server 4. Edit standalone.xml: <security-domain name="gatein-domain" cache-type="default"> <authentication> <login-module code="org.exoplatform.web.security.InitSharedStateLoginModule" flag="required"> <module-option name="portalContainerName" value="portal"/> <module-option name="realmName" value="gatein-domain"/> </login-module> <login-module code="org.exoplatform.services.security.jaas.SharedStateLoginModule" flag="required"> <module-option name="portalContainerName" value="portal"/> <module-option name="realmName" value="gatein-domain"/> </login-module> <login-module code="org.exoplatform.services.organization.idm.CustomMembershipLoginModule" flag="required"> <module-option name="portalContainerName" value="portal"/> <module-option name="realmName" value="gatein-domain"/> <module-option name="membershipType" value="member"/> <module-option name="groupId" value="/platform/test"/> </login-module> <login-module code="org.exoplatform.services.security.j2ee.JBossAS7LoginModule" flag="required"> <module-option name="portalContainerName" value="portal"/> <module-option name="realmName" value="gatein-domain"/> </login-module> </authentication> </security-domain> 5. Start the server 6. Install byteman against the JPP pid 7. Submit the attached byteman rules. This will simulate a DB error during CustomMembershipLoginModule.addUserToPlatformUsers 8. Log in as user 'demo' Without the fix for GTNPORTAL-3572, the exception will not be handled properly in MembershipDAOImpl. This leads to the following: * JPP 6.1.1 / GateIn 3.6: An Identity operation error is logged: Caused by: org.hibernate.TransactionException: nested transactions not supported The user is not logged in, and further requests using this thread are broken. * JPP 6.2 / GateIn 3.8: IDM error recovery is happening on CustomMembershipLoginModule.end -> PicketLinkIDMOrganizationServiceImpl.endRequest. Further requests using this thread are handled properly. Nevertheless, proper exception handling inside MembershipDAOImpl is better instead of waiting on the lifecycle end method to clean up the transaction.
Created attachment 977804 [details] Byteman rule to simulate DB exception
https://github.com/gatein/gatein-portal/pull/925 was merged in upstream
Martin, I get the same exception for 6.2.0.ER9 and 6.1.1.GA with your byteman script, but it's different from what you wrote in Comment 2: ... org.hibernate.exception.GenericJDBCException: could not insert ...
Created attachment 1002845 [details] GenericJDBCException - 6.1.1.GA
Created attachment 1002846 [details] GenericJDBCException - 6.2.0.ER9
Btw, the GenericJDBCException already appears during portal startup. I never get to the demo login part.
Tomas, are you starting JPP with the byteman script already? The steps to follow should be: - start JPP to create a new group and user, stop JPP again - edit standalone.xml to add the CustomMembershipLoginModule with the new group - start JPP again (no byteman) - after JPP has started, install the byteman rule - try to log in with the new test user (not yet assigned to the new group) HTH, Martin
Looks like I missed few steps, sorry. I will retest.
I've retested and I get the same stacktrace as Tomas (https://bugzilla.redhat.com/attachment.cgi?id=1002846). According to IRC conversation with Martin, the db exception is handeles and the issue can be cosidered as fixed, so I'm changing status to verified.