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 cms/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 ="com.arsdigita.cms.ui.ContentItemPage,com.arsdigita.cms.dispatcher.ContentSectionDispatcher,com.arsdigita.cms.ContentSection,com.arsdigita.cms.dispatcher.Utilities,com.arsdigita.dispatcher.*,java.util.Date,com.arsdigita.web.LoginSignal,org.apache.log4j.Logger,com.arsdigita.kernel.DatabaseTransaction,com.arsdigita.web.RedirectSignal" %><%DispatcherHelper.cacheDisable(response);%> - +<%@ page + import ="com.arsdigita.cms.ui.ContentItemPage,com.arsdigita.cms.dispatcher.ContentSectionDispatcher,com.arsdigita.cms.ContentSection,com.arsdigita.cms.dispatcher.Utilities,com.arsdigita.dispatcher.*,java.util.Date,com.arsdigita.web.LoginSignal" %><%DispatcherHelper.cacheDisable(response);%> <%-- 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): 6.0 How reproducible: Always Steps to Reproduce: 1. Start WebSphere 4.0.2 2. Try to publish something. 3. Actual results: the item should be published Expected results: we get an error Additional info:
With our move to support Servlet 2.3 exclusively, we can actually take advantage of 2.3 spec and eliminate RedirectSignal.
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.
Closing old tickets