2 Replies Latest reply on Nov 12, 2007 8:40 AM by pmuir

    handling FileUploadException exception

      Hi,

      I have the problem that my facesMessages get lost when handling org.jboss.seam.web.FileUploadException.

      I have this in pages.xml:

      <exception class="org.jboss.seam.web.FileUploadException">
       <redirect view-id="/welcome.xhtml">
       <message severity="ERROR">
       File is too big.
       </message>
       </redirect>
       </exception>


      When I raise a FileUploadException from my application code the exception gets handled as expected and the correct faces message is displayed. When Seam generates the exception in the MultipartFilter, welcome.xhtml is invoked, but the message is lost. After some debugging I think I found the cause of the problem: in this case the faces message is generated in a different conversation, and even in a different session (!) than the current user conversation/session. So the FacesMessages object which contains the correct message is not available any more in welcome.xhtml.

      Is there an easy workaround for this issue? Currently I have no other idea than not using message at all, but to redirect to a specific error page that knows that it was a FileUploadException.

        • 1. Re: handling FileUploadException exception

          I found the cause of the problem: I do not use cookies in my web application for session tracking (Tomcat is set to cookies="false"). Because of this, Seam looses the current session, and renders the error page in a new session. If I switch on cookies, the exception handling works also for the exception generated by MultipartFilter.

          I guess it should be quite a common situation to have a web application where using cookies is not allowed. (For example I am not allowed to use cookies.) Could the Seam exception handling be prepared for this situation, or is it a fundamental problem that cannot be easily solved?

          • 2. Re: handling FileUploadException exception
            pmuir

            Please file a JIRA issue for this, we can see if we can work around it.