seam-generated, libs removed

It seems that any exceptions (SQLException, NPE, etc), that the methods throw are not being caught at this time (1.7.0 and 1.7.1). Also tried without Seam (using Facelets and ICEfaces-1.7.1) and the redirection is not occuring (when placing the following in web.xml:-

<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.seam</location>
</error-page>

(also tried with various exceptions from methods tied to actionListeners on ice:commandLinks--> stack trace is dumped to AS console, but redirection not occurring).

The fix for ICE-3332 does not resolve the problem with seam application. Seam exception redirecting still not working.

Judy says:

I have created 3 separate applications to trace through this, 1=Seam only, 2=ICEfaces facelets only, 3=Seam plus ICefaces.

What is happening is the following:-

1) Seam catches the exception and wraps it in it's own Exception Class. ExceptionFilter then does it's thing and ends the conversation nicely, created a MockFacesContext and creates a new temporary conversation, then uses FacesManager/Manager to do redirect() and redirection is based on rules in pages.xml.
2) ICEfaces:- exception caught in ViewBoundServer and thrown to be caught in MainServlet. Regular jsf stuff will do redirect based on what is in web.xml for this.
3) ICEfaces with Seam. The ViewBoundServer finds the exception and throws it, then the view is released (contexts and state, etc released), BUT....the ExceptionFilter then tries to do it's thing....but no contexts there no conversation to restore. It ends up creating MockFacesContext with a new temporary conversation and tries to do the redirect, but it just hangs (forever). Doesn't come back to MainServlet.

This reflects the same issue as when a user has incorrect permissions on various methods.....since this is caught the same way in seam, we don't do the proper redirect. Just an exception and the hanging.

After some extensive research and trying different potential fixes I came to the following conclusion:

I think the offending Seam class is org.jboss.seam.mock.MockViewHandler, which is created when the org.jboss.seam.web.ExceptionFilter catches an exception. It contains the getActionURL(FacesContext, String) which seems to be used to determine the URI to redirect to:

@Override
public String getActionURL(FacesContext ctx, String viewId)
{
String contextPath = ctx.getExternalContext().getRequestContextPath();
String pathInfo = ctx.getExternalContext().getRequestPathInfo();
String servletPath = ctx.getExternalContext().getRequestServletPath();

if (Strings.isEmpty(pathInfo))

else

}

In combination with ICEfaces when the NPE is forcibly thrown the Strings in this part of the code contain the following values (with some comments in the brackets after the values):

• viewId: /error.xhtml (the desired error page defined in pages.xml)
• contextPath: /ICE (the ICEfaces application name)
• pathInfo: /send-receive-updates (ICEfaces JavaScript Bridge specific)
• servletPath: /block (ICEfaces JavaScript Bridge specific)

This will result in a redirect URI of /ICE/block/error.xhtml (and some query part, which I will ignore for the moment) which is incorrect in my opinion. The else-block in the method doesn't take the details of viewId into account. As the desired error page is specified as /error.xhtml the resulting redirect URI should toss the servletPath as the viewId starts with a slash. (On a side note, if a full URI is specified in the pages.xml, all the elements (contextPath, pathInfo and servletPath should be ignored and the viewId itself should be the redirect URI.)

Additionally, the "xhtml" part of the resulting redirect URI doesn't seem to be replaced by "seam". I'm not sure in this case if we do something wrong that causes this.

By the way, I used JBoss Seam 2.0.2.SP1 for all of this.

Ted contacted somebody at Seam to verify my suspicion.

created JBSEAM-3426
https://jira.jboss.org/jira/browse/JBSEAM-3426

after Pete's fix for JBSEAM-3426, this will work if you put .seam extension to redirects for exception handling with seam (eg: <redirect view-id="/error.seam">). BUT we can do better than this if we don't have ctx.getExternalContext().getRequestPathInfo() return as null. Looking at ServletExternalContext, the getRequestServletPath evaluates to what requestPathInfo should be, so could set RequestPathInfo to requestServletPath if exception caught and is Seam application (in com.icesoft.faces.webapp.http.coreReceiveSendUpdates).

changes made to PortletExternalContext and ServletExternalContext to ensure that the request variables are maintained in the externalContext for Seam redirection.

tested on jboss-4.2.3.GA as well. Requires Seam trunk (for Pete's fix) and ICEfaces fix will be in 1.7.2 release

This change is causing regressions in server-push with Seam:

08:28:18,568 ERROR [STDERR] Exception in thread "Render Thread - 22"
08:28:18,568 ERROR [STDERR] java.lang.StackOverflowError
08:28:18,568 ERROR [STDERR] at org.apache.catalina.connector.Request.setAttribute(Request.java:1424)
08:28:18,568 ERROR [STDERR] at org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503)
08:28:18,568 ERROR [STDERR] at javax.servlet.ServletRequestWrapper.setAttribute(ServletRequestWrapper.java:284)
08:28:18,568 ERROR [STDERR] at com.icesoft.faces.webapp.http.servlet.ServletRequestAttributes.setAttribute(ServletRequestAttributes.java:28)
08:28:18,568 ERROR [STDERR] at com.icesoft.faces.webapp.http.servlet.ServletEnvironmentRequest.setAttribute(ServletEnvironmentRequest.java:216)
08:28:18,568 ERROR [STDERR] at com.icesoft.faces.webapp.http.servlet.ServletRequestAttributeMap.setAttribute(ServletRequestAttributeMap.java:25)
08:28:18,568 ERROR [STDERR] at com.icesoft.faces.context.AbstractCopyingAttributeMap.put(AbstractCopyingAttributeMap.java:22)
08:28:18,568 ERROR [STDERR] at java.util.Collections$SynchronizedMap.put(Unknown Source)
08:28:18,568 ERROR [STDERR] at org.jboss.seam.contexts.BasicContext.set(BasicContext.java:85)
08:28:18,568 ERROR [STDERR] at org.jboss.seam.Component.newInstance(Component.java:2031)

Seems like the push issues are not related to this issue. New JIRA for those is ICE-3577.

Marking Fixed again.

for pre jboss-seam-2.1.0.GA releases, you can still do redirection with ICEfaces and Seam by configuring the following:_

1) in web.xml add the following, and ensure error.xhtml (or whatever extension is defined in context-param = javax.faces.DEFAULT_SUFFIX) is included in the project:-
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.seam</location>
</error-page>

Note that multiple exceptions may be listed going to numerous error pages that are defined.

2) Add the following to components.xml:-

<web:exception-filter url-pattern="*.seam"/>

and define the namespace for web:- xmlns:web="http://jboss.com/products/seam/web" with schema location= http://jboss.com/products/seam/web http://jboss.com/products/seam/web-2.0.xsd

(for 2.0.x)

That's it. You can't get the actual value of the exception, but if you defined an error page for each type of exception you wanted to capture as well as a general catch-all, you could have static pages to inform the user what had happened.

Just to make things clear(er?):-

what has been explained above is a "workaround" for versions of Seam previous to jboss-seam-2.1.0. The fix has been applied to both jboss-seam-2.1.0 as well as ICEfaces-1.7.2 to enable the seam redirection navigation (dependent on rules defined in pages.xml) to work.