Bug 108603 - WebSphere does not like RedirectSignal
Summary: WebSphere does not like RedirectSignal
Alias: None
Product: Red Hat Enterprise CMS
Classification: Retired
Component: ui   
(Show other bugs)
Version: nightly
Hardware: All Linux
Target Milestone: ---
Assignee: ccm-bugs-list
QA Contact: Jon Orris
Depends On:
Blocks: 108447
TreeView+ depends on / blocked
Reported: 2003-10-30 16:28 UTC by Randy Graebner
Modified: 2007-04-18 16:58 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-05 17:19:55 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Randy Graebner 2003-10-30 16:28:00 UTC
Description of problem:
When publishign or doing many other things with Workflow/Lifecycle, the
/packages/content-section/www/admin/item.jsp page calls the page to dispatch and
then a RedirectSignal is thrown.  However, WebSphere 4.0.2 does not handle the
RedirectSignal correctly.  The BaseServlet does not catch it.  Instead, it
almost appears as though WebSphere is trying to serve the jsp and it sees the
Error and it reports it back as a "java.lang.Exception" with no message at all.  

This is obviously a problem since it means that we cannot publish with 4.0.2.

The patch below fixes the problem but it does not seem right to have to catch
the error on every jsp.  Extending BaseJSP does not work.

diff -u intragroupe/web/packages/content-section/www/admin/item.jsp
--- intragroupe/web/packages/content-section/www/admin/item.jsp	Thu Oct 30
11:08:48 2003
+++ cms/web/packages/content-section/www/admin/item.jsp	Tue Aug 19 08:38:56 2003
@@ -1,6 +1,5 @@
-<%@ page extends="com.arsdigita.web.BaseJSP"
-    import
+<%@ page 
+    import
     <%-- NB. The above cacheDisable command must be on the first line of the jsp
              since the header must be written before any data is output --%>

@@ -55,19 +26,9 @@
         timestamp = new Date();
-    try {
-        RequestContext context = DispatcherHelper.getRequestContext(request);
-        itemPage.init();
-        itemPage.dispatch(request, response, context);
-    } catch (RedirectSignal signal) {
-        if (signal.isCommitRequested()) {
-            (new DatabaseTransaction()).commit();
-        } else {
-            (new DatabaseTransaction()).abort();
-        }
-        final String url = response.encodeRedirectURL(signal.getDestinationURL());
-        response.sendRedirect(url);
-    }
+    RequestContext context = DispatcherHelper.getRequestContext(request);
+    itemPage.init();
+    itemPage.dispatch(request, response, context);
Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Start WebSphere 4.0.2
2.  Try to publish something.
Actual results:
the item should be published

Expected results:
we get an error

Additional info:

Comment 1 Richard Li 2003-10-30 17:20:51 UTC
With our move to support Servlet 2.3 exclusively, we can actually take advantage
of 2.3 spec and eliminate RedirectSignal.

Comment 2 Daniel Berrange 2003-10-30 17:55:18 UTC
Yes, what Richard said :-) Cardinal rule of C++ & Java is (or at least should be
;-) don't use exceptions for flow control. 

Concretly, we should implement a javax.servlet.ServletFilter that wraps the
incoming request with some subclass of
javax.servlet.http.HttpServletRequestWrapper. This can intercept calls to
sendRedirect & do what ever it needs to. What ever code calls send redirect
can abort / commit the transaction as required.

This wrapper can also deal with parsing multi-part for posts, removing the need
for us to go through the whole wrap/unwrap business when forwarding & receiving
forwarded requests to/form other servlets.

Comment 3 Jon Orris 2006-09-05 17:19:55 UTC
Closing old tickets

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