Bug 1068709
| Summary: | Unsuccessful REST request results in HTTP code 500 with exception not related to the actual error | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] JBoss BRMS Platform 6 | Reporter: | Petr Široký <psiroky> | ||||
| Component: | Business Central | Assignee: | Roger Martínez <romartin> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Petr Široký <psiroky> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 6.0.0 | CC: | kverlaen, lpetrovi, rrajasek | ||||
| Target Milestone: | ER2 | ||||||
| Target Release: | 6.0.1 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-08-06 19:57:28 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Hi Marco, would you mind taking a look at this please? Thanks, Mike Seems to be related to issue with modules Kris, that might be the case. I just quickly explored the distributions for 6.0.0-GA and 6.0.1-ER1 and the structure regarding the modules has indeed changed. 6.0.0-GA (find . -name "*solder*"): ----------------------------------- ./standalone/deployments/business-central.war/WEB-INF/lib/org.jboss.solder-solder-impl-jar-webfragment.jar ./modules/system/layers/bpms/org/jboss/solder ./modules/system/layers/bpms/org/jboss/solder/main/solder-impl-3.2.1.Final.jar ./modules/system/layers/bpms/org/jboss/solder/main/solder-logging-3.2.1.Final.jar ./modules/system/layers/bpms/org/jboss/solder/main/solder-api-3.2.1.Final.jar 6.0.1-ER1 (find . -name "*solder*"): ------------------------------------ ./standalone/deployments/business-central.war/WEB-INF/lib/solder-impl-3.2.1.Final.jar ./modules/system/layers/bpms/org/jboss/solder ./modules/system/layers/bpms/org/jboss/solder/main/solder-logging-3.2.1.Final.jar ./modules/system/layers/bpms/org/jboss/solder/main/solder-api-3.2.1.Final.jar Petr, Kris, You are right about the module differences. This issue is a duplicate and has been fixed in - https://bugzilla.redhat.com/show_bug.cgi?id=1067048 Please, take a look at the last comment for that issue which explains the problem and the solution. @Petr: Can you give me feedback about is this issue it's still not happening since the BZ 1067048 has been closed? Thanks in advance. Roger (In reply to Petr Siroky from comment #3) > Kris, that might be the case. I just quickly explored the distributions for > 6.0.0-GA and 6.0.1-ER1 and the structure regarding the modules has indeed > changed. > > 6.0.0-GA (find . -name "*solder*"): > ----------------------------------- > ./standalone/deployments/business-central.war/WEB-INF/lib/org.jboss.solder- > solder-impl-jar-webfragment.jar > ./modules/system/layers/bpms/org/jboss/solder > ./modules/system/layers/bpms/org/jboss/solder/main/solder-impl-3.2.1.Final. > jar > ./modules/system/layers/bpms/org/jboss/solder/main/solder-logging-3.2.1. > Final.jar > ./modules/system/layers/bpms/org/jboss/solder/main/solder-api-3.2.1.Final.jar > > 6.0.1-ER1 (find . -name "*solder*"): > ------------------------------------ > ./standalone/deployments/business-central.war/WEB-INF/lib/solder-impl-3.2.1. > Final.jar > ./modules/system/layers/bpms/org/jboss/solder > ./modules/system/layers/bpms/org/jboss/solder/main/solder-logging-3.2.1. > Final.jar > ./modules/system/layers/bpms/org/jboss/solder/main/solder-api-3.2.1.Final.jar Roger, the BZ 1067048 has not been closed, just moved to MODIFIED. That means it should be fixed in next product build ER2. I will let you know if this issue is fixed when the ER2 arrives. Thanks Petr, Only if it's possible for you... If I provide you both bpms layer ZIP and the skinny WAR can you try it instead of waiting for the release?? I would like to be sure that this issue is verified before the tomorrow's release but i have still a lot of pending work for today. Not sure if I'll have enough time... Thanks (In reply to Petr Siroky from comment #5) > Roger, > > the BZ 1067048 has not been closed, just moved to MODIFIED. That means it > should be fixed in next product build ER2. I will let you know if this issue > is fixed when the ER2 arrives. I have provided BPMS EAP modules distribution aritfacts to Petr and he had tested the issue: "I think we can consider the issue to be solved, I was not able to reproduce the exception - so please move the BZ to modified and I will verify again with the next product build" If the error reappears please reopen the bug. Thanks Correct exception is thrown, but the server still returns the code 500. I am not sure that is correct. I will create a new BZ if I found out it is indeed a bug. Verified fixed in 6.0.1-ER2. |
Created attachment 866176 [details] Internal error 500 response Description of problem: If the REST request ends with an error (like when user wants to clone repository and gives the name that already exists or tries to delete non-existent repository) the server returns a 500 HTTP error code with following exception, which is _not_ related to the real problem that occurred (e.g. duplicate repo name): java.lang.IllegalAccessError: tried to access method org.jboss.solder.exception.control.ExceptionStack.dropCause()V from class org.jboss.solder.exception.control.ExceptionHandlerDispatch The server should return HTTP code "400 Bad Request" or something like that with clear error message. See the attached HTML page with the complete response body. Version-Release number of selected component (if applicable): 6.0.1-ER1 How reproducible: Always Steps to Reproduce: 1. Send REST request with following json payload: {"name":"jbpm-playground", "description":"", "userName":"", "password":"", "requestType":"clone", "gitURL":"git:droolsjbpm/jbpm-playground.git"} 2. Sent the above request once more. Actual results: Internal error (500) HTTP response with ugly stacktrace, not related to the actual reason why the request failed. Expected results: I guess some kind of 4xx HTTP response with clear error message. Additional info: