Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 533052

Summary: Exceptions incorrectly return requestStatus == SUCCESS
Product: [Retired] Dogtag Certificate System Reporter: John Dennis <jdennis>
Component: Certificate ManagerAssignee: RHCS Maintainers <rhcs-maint>
Status: CLOSED EOL QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.2CC: dpal, jgalipea, rcritten
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-27 20:04:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 688231    
Attachments:
Description Flags
patch none

Description John Dennis 2009-11-04 20:09:02 UTC 
The requestStatus value is set to SUCCESS when an unexpectedError exception occurs. Since the requestStatus value is used to determine the outcome of the request the receiver will not recognize that the result was actually not successful as reported, but rather an exception occurred. As it stands now the only way to detect an exception is to ignore the requestStatus value and look for the presence of fixed.unexpectedError.

Here is how this happens:

in CMSServlet.service a new CMSRequest object is created, it's status (e.g. mStatus) is initialized to SUCCESS. It is assigned to the cmsRequest variable.

The cmsRequest object is passed to the servlet's process() method. If an exception occurs while in the process() method control returns immediately to the catch block for EBaseException, which then passes the same cmsRequest object to renderException().

renderException then calls the getTemplateParameters() method from the GenUnexpectedErrorTemplateFiller class passing the same cmsRequest object. It gets the status from the cmsRequest object via getStatus(), which since it's never been modified since the object was created is still SUCCESS. So it inserts a requestStatus value of SUCCESS into the CMSTemplateParams it will subsequently returns.

CMSServlet.renderException() and GenUnexpectedErrorTemplateFiller.getTemplateParameters() should probably both force the status to CMSRequest.EXCEPTION by calling cmsRequest.setStatus(CMSRequest.EXCEPTION) since by the time either of these routines are called it's a given the status should be CMSRequest.EXCEPTION no matter what the current value of CMSRequest.mStatus is.
Comment 1 John Dennis 2009-11-12 15:51:55 UTC 
Created attachment 369241 [details]
patch
Comment 2 Andrew Wnuk 2009-11-18 00:45:13 UTC 
attachment (id=369241) +awnuk

It looks to me that that renderException() set request status to CMSRequest.EXCEPTION before getTemplateParams() is called.
Is there any reason set request status again inside getTemplateParams()?
Comment 3 John Dennis 2009-11-18 16:59:10 UTC 
Re comment #2. This is a good observation. In the current calling sequence resetting the status is redundant. However, also assuring it's set in getTemplateParams() is defensive programming in the service of robustness in case a different code path is taken for some reason.