Bug 1004213 - REST MOP Import doesn't detect errors on commit
REST MOP Import doesn't detect errors on commit
Product: JBoss Enterprise Portal Platform 6
Classification: JBoss
Component: Portal (Show other bugs)
Unspecified Unspecified
high Severity medium
: DR02
: 6.1.1
Assigned To: Boleslaw Dawidowicz
Dominik Pospisil
Depends On:
  Show dependency treegraph
Reported: 2013-09-04 04:23 EDT by Toshiya Kobayashi
Modified: 2014-02-18 08:05 EST (History)
7 users (show)

See Also:
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".
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
throwExOnExoCommit.rule (405 bytes, text/plain)
2013-09-04 04:29 EDT, Toshiya Kobayashi
no flags Details
throwExOnExoCommit-fix.rule (413 bytes, text/plain)
2013-11-13 00:10 EST, Toshiya Kobayashi
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker GTNPORTAL-3257 Major Resolved REST MOP Import doesn't detect errors on commit 2014-02-18 08:11:42 EST

  None (edit)
Description Toshiya Kobayashi 2013-09-04 04:23:33 EDT
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 04:29:05 EDT
Created attachment 793543 [details]
Comment 2 Toshiya Kobayashi 2013-09-04 04:29:45 EDT
Attached throwExOnExoCommit.rule which I tested with JPP 6.0.0
Comment 5 Toshiya Kobayashi 2013-11-13 00:10:41 EST
Created attachment 823245 [details]
Comment 6 Boleslaw Dawidowicz 2013-11-13 10:12:56 EST
Looks like fixed in JCR 1.16.x Would require backport to 1.15.x
Comment 7 JBoss JIRA Server 2013-12-03 07:41:25 EST
Nicolas Filotto <nfilotto@exoplatform.com> 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-05 19:57:08 EST
Nick Scavelli <nscavell@redhat.com> 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 13:58:25 EST
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-10 22:14:47 EST
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.


Comment 11 Boleslaw Dawidowicz 2014-02-17 06:56:09 EST
Adding doc text proposal

Note You need to log in before you can comment on or make changes to this bug.