Bug 1004213 - REST MOP Import doesn't detect errors on commit
Summary: REST MOP Import doesn't detect errors on commit
Keywords:
Status: VERIFIED
Alias: None
Product: JBoss Enterprise Portal Platform 6
Classification: JBoss
Component: Portal
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: DR02
: 6.1.1
Assignee: Boleslaw Dawidowicz
QA Contact: Tomas Kyjovsky
URL:
Whiteboard: JCR
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-04 08:23 UTC by Toshiya Kobayashi
Modified: 2019-01-01 03:40 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
If an error occurs during Portal import at the JCR level using a REST call, then the transaction is rolled back and import fails. But it was discovered that REST call responded with the code "200 OK" indicating that import was successful, which is incorrect. The fix in the code returns correct error code "500".
Clone Of:
Environment:
Last Closed:
Type: Bug

Attachments (Terms of Use)
throwExOnExoCommit.rule (405 bytes, text/plain)
2013-09-04 08:29 UTC, Toshiya Kobayashi 		no flags Details
throwExOnExoCommit-fix.rule (413 bytes, text/plain)
2013-11-13 05:10 UTC, Toshiya Kobayashi 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker GTNPORTAL-3257 0 Major Resolved REST MOP Import doesn't detect errors on commit 2014-02-18 13:11:42 UTC

Description Toshiya Kobayashi 2013-09-04 08:23:33 UTC 
Description of problem:

Platform BZ for https://issues.jboss.org/browse/GTNPORTAL-3257

Steps to Reproduce:
1. Call REST MOP Import (e.g. curl command in GTNPORTAL-3257)
2. Throw an Exception on JCR commit (e.g. using Byteman)

Actual results:

Transaction is rolled back. But REST response is 200 OK.

Expected results:

Transaction is rolled back. REST response is 500 (or something appropriate?).
Comment 1 Toshiya Kobayashi 2013-09-04 08:29:05 UTC 
Created attachment 793543 [details]
throwExOnExoCommit.rule
Comment 2 Toshiya Kobayashi 2013-09-04 08:29:45 UTC 
Attached throwExOnExoCommit.rule which I tested with JPP 6.0.0
Comment 5 Toshiya Kobayashi 2013-11-13 05:10:41 UTC 
Created attachment 823245 [details]
throwExOnExoCommit-fix.rule
Comment 6 Boleslaw Dawidowicz 2013-11-13 15:12:56 UTC 
Looks like fixed in JCR 1.16.x Would require backport to 1.15.x
Comment 7 JBoss JIRA Server 2013-12-03 12:41:25 UTC 
Nicolas Filotto <nfilotto> made a comment on jira GTNPORTAL-3257

This issue cannot be fixed as expected so we will simply add an error message in the log file instead. Please refer to https://jira.exoplatform.org/browse/WS-284 and https://jira.exoplatform.org/browse/WS-285 for more details
Comment 8 JBoss JIRA Server 2013-12-06 00:57:08 UTC 
Nick Scavelli <nscavell> made a comment on jira GTNPORTAL-3257

Adding a call to ChromatticManager.endRequest during the import should help bring any issues that may surface when the REST container ends the RequestLifecyle. This issue depends on https://jira.exoplatform.org/browse/WS-285 which reverts the commit of https://jira.exoplatform.org/browse/WS-284.
Comment 9 Tomas Kyjovsky 2013-12-12 18:58:25 UTC 
I reproduced the issue on DR01 and verified the fix with DR02, using throwExOnExoCommit-fix.rule.

On DR02 I got:

HTTP/1.1 500 Internal Server Error
...
{
   "failure": "Error during import. Tasks successfully rolled back. Portal should be back to consistent state.",
   "operationName": "import-resource"
}
Comment 10 Jared MORGAN 2014-02-11 03:14:47 UTC 
Hey Bolek

As this issue has two customer cases attached to it, we should probably have a Known Issue written up for it.

Please reassign to anyone else if they can better create the release note.

Cheers

J
Comment 11 Boleslaw Dawidowicz 2014-02-17 11:56:09 UTC 
Adding doc text proposal
Note You need to log in before you can comment on or make changes to this bug.