[JBoss JIRA] (GTNPORTAL-3539) Do not recover IDM transaction if exception occurs during a search.
by Trong Tran (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3539?page=com.atlassian.jira.pl... ]
Trong Tran updated GTNPORTAL-3539:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/gatein/gatein-portal/pull/908
After discussing in the email, we decided to handle just specific exception called by IDM PersistenceManagerImpl for NULL check. Something like:
{code}
try {
foundUser = session.getPersistenceManager().findUser(userName);
} catch (IllegalArgumentException iae) {
// findUser was called with null argument. Do something needed for your business logic (Rethrow exception or at least log error)
} catch (Exception e) {
handleException("Cannot obtain user: " + userName + "; ", e);
}
{code}
> 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("Not found user instance ", user != null);
> userHandler_.removeUser(USER, true);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (GTNPORTAL-3549) Don't validate username when edit user
by Tuyen Nguyen The (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3549?page=com.atlassian.jira.pl... ]
Tuyen Nguyen The updated GTNPORTAL-3549:
----------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/gatein/gatein-portal/pull/910
> Don't validate username when edit user
> --------------------------------------
>
> Key: GTNPORTAL-3549
> URL: https://issues.jboss.org/browse/GTNPORTAL-3549
> Project: GateIn Portal
> Issue Type: Bug
> Reporter: Tuyen Nguyen The
> Assignee: Tuyen Nguyen The
> Attachments: username_validator.png
>
>
> The case is:
> - We configure max length of username to 100
> - Create an user with username is a long string, for example "testuserwithlongusernamehere" -> Create user successfully
> - Then we reconfigure max-length of username to 25 character -> Now, we can only create user with length of username less than 25
> - Go to User Management and edit user "testuserwithlongusernamehere", update some info like firstName, lastName
> - Click to save button => Warning message is shown and we can not save user info
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (GTNPORTAL-3549) Don't validate username when edit user
by Tuyen Nguyen The (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3549?page=com.atlassian.jira.pl... ]
Tuyen Nguyen The updated GTNPORTAL-3549:
----------------------------------------
Attachment: username_validator.png
> Don't validate username when edit user
> --------------------------------------
>
> Key: GTNPORTAL-3549
> URL: https://issues.jboss.org/browse/GTNPORTAL-3549
> Project: GateIn Portal
> Issue Type: Bug
> Reporter: Tuyen Nguyen The
> Assignee: Tuyen Nguyen The
> Attachments: username_validator.png
>
>
> The case is:
> - We configure max length of username to 100
> - Create an user with username is a long string, for example "testuserwithlongusernamehere" -> Create user successfully
> - Then we reconfigure max-length of username to 25 character -> Now, we can only create user with length of username less than 25
> - Go to User Management and edit user "testuserwithlongusernamehere", update some info like firstName, lastName
> - Click to save button => Warning message is shown and we can not save user info
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (GTNPORTAL-3549) Don't validate username when edit user
by Tuyen Nguyen The (JIRA)
Tuyen Nguyen The created GTNPORTAL-3549:
-------------------------------------------
Summary: Don't validate username when edit user
Key: GTNPORTAL-3549
URL: https://issues.jboss.org/browse/GTNPORTAL-3549
Project: GateIn Portal
Issue Type: Bug
Reporter: Tuyen Nguyen The
Assignee: Tuyen Nguyen The
The case is:
- We configure max length of username to 100
- Create an user with username is a long string, for example "testuserwithlongusernamehere" -> Create user successfully
- Then we reconfigure max-length of username to 25 character -> Now, we can only create user with length of username less than 25
- Go to User Management and edit user "testuserwithlongusernamehere", update some info like firstName, lastName
- Click to save button => Warning message is shown and we can not save user info
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (GTNPORTAL-3539) Do not recover IDM transaction if exception occurs during a search.
by Trong Tran (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3539?page=com.atlassian.jira.pl... ]
Trong Tran updated GTNPORTAL-3539:
----------------------------------
Description:
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("Not found user instance ", user != null);
userHandler_.removeUser(USER, true);
}
{code}
was:
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}
> 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("Not found user instance ", user != null);
> userHandler_.removeUser(USER, true);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 7 months
[JBoss JIRA] (GTNPORTAL-3539) Do not recover IDM transaction if exception occurs during a search.
by Trong Tran (JIRA)
[ 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)
9 years, 7 months
[JBoss JIRA] (GTNPORTAL-3539) Do not recover IDM transaction if exception occurs during a search.
by Trong Tran (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3539?page=com.atlassian.jira.pl... ]
Trong Tran edited comment on GTNPORTAL-3539 at 10/6/14 6:32 AM:
----------------------------------------------------------------
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 ?
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 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)
9 years, 7 months
[JBoss JIRA] (GTNPORTAL-3539) Do not recover IDM transaction if exception occurs during a search.
by Trong Tran (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3539?page=com.atlassian.jira.pl... ]
Trong Tran edited comment on GTNPORTAL-3539 at 10/6/14 6:14 AM:
----------------------------------------------------------------
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 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, when the transaction rollback should not be a problem. Is there any IDM expert who can 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)
9 years, 7 months