[
https://issues.jboss.org/browse/GTNPORTAL-3539?page=com.atlassian.jira.pl...
]
Trong Tran edited comment on GTNPORTAL-3539 at 10/6/14 11:26 AM:
-----------------------------------------------------------------
I find that this happens when we pass username with NULL value to
UserHandler#findUserByName() method. It indirectly calls
org.picketlink.idm.api.PersistenceManager.findUser(String) as below:
{code}
try {
foundUser = session.getPersistenceManager().findUser(userName);
} catch (Exception e) {
handleException("Cannot obtain user: " + userName + "; ",
e);
}
{code}
The #findUser() method throws an exception, then the rollback of IDM transaction is
performed inside the #handleException method (by indirectly calling #recoverFromIDMError
method). That's why it reverts the new user was created before.
This not only impacts to UserHandler#findUserByName() BUT also for every place that is
using PersistenceManager#findUser() --> So the *workaround* is to remove the
#handleException in the try-catch block.
============
However, what really concerns me is about the
org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl.flush()
which is already called before PersistenceManager#findUser() performed. It looks like the
pending changes should be saved at this time, then the transaction rollback should not be
a problem. Is there any IDM expert who can help to confirm this ?
was (Author: trong.tran):
I find that this happens when we pass username with NULL value to
UserHandler#findUserByName() method. It indirectly executes
org.picketlink.idm.api.PersistenceManager.findUser(String) as below:
{code}
try {
foundUser = session.getPersistenceManager().findUser(userName);
} catch (Exception e) {
handleException("Cannot obtain user: " + userName + "; ",
e);
}
{code}
The #findUser() method throws an exception, then the rollback of IDM transaction will be
indirectly executed inside the #handleException method (by calling #recoverFromIDMError
one). That's why it reverts the new user was created before.
This not only impacts to UserHandler#findUserByName() BUT also for every place that is
using PersistenceManager#findUser() --> so the *workaround* is to remove the
#handleException in the try-catch block.
============
However, what really concerns me is about the
org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl.flush()
which is called almost everywhere before PersistenceManager#findUser() done. It looks like
the pending changes should be saved at this time, then the transaction rollback should not
be a problem. Is there any IDM expert who can help to confirm this ?
Do not recover IDM transaction if exception occurs during a search.
-------------------------------------------------------------------
Key: GTNPORTAL-3539
URL:
https://issues.jboss.org/browse/GTNPORTAL-3539
Project: GateIn Portal
Issue Type: Task
Affects Versions: 3.7.0.Final
Reporter: Tran Trung Thanh
Priority: Minor
Fix For: 3.9.0.Final
If user meets an exception during a search, it is not neccessary to recover transaction.
Unit test
{code:java}
@Test
public void testFailDuringSearch() throws Exception {
String USER = "test";
createUser(USER);
userHandler_.findUserByName(null);
User user = userHandler_.findUserByName(USER);
assertTrue("Found user instance ", user != null);
userHandler_.removeUser(USER, true);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)