exception handling - likely bug that needs to be investigate

[wschwendt]

I'd like to mention the following behavior which looks to me like a bug.

Seam version used: CVS Based Seam 2
JBoss AS 4.2.1 GA

How to reproduce:

Deploy the seamdiscs example with the facelets.DEVELOPMENT config parameter set to false in web.xml. (Note: in web.xml, as checked out from the Seam CVS repository, facelets.DEVELOPMENT is set to true, but we need to set it to false in order to test how exceptions are handled).

After deployment access the following URL:

http://127.0.0.1:8080/seam-discs/artists.seam?artistId=200&actionOutcome=artist


In this URL the artistId is deliberately set to a value for which no entity exists in the database. The intention is to trigger an EntityNotFoundException when org.jboss.seam.framework.Home tries to load the artist (entity instance) with id 200.


What happens after above URL is accessed:

Seam redirects to
http://127.0.0.1:8080/seam-discs/artist.seam/error.xhtml?cid=6


But it actually is supposed to redirect to
http://127.0.0.1:8080/seam-discs/error.seam?cid=6
, given the exception definition in pages.xml for the seamdiscs example.

[wschwendt]

I'm purchasing a 'd' char, the subject in the original post should read:

exception handling - likely bug that needs to be investigated

[pmuir]

Yes, others have reported this, but no JIRA issue has been created. Please create one :)

[wschwendt]

ok, I'll do in a moment.

[wschwendt]

http://jira.jboss.org/jira/browse/JBSEAM-1776

[wschwendt]

Don't really understand the code yet, but the org.jboss.seam.mock.MockViewHandler.getActionURL(FacesContext ctx, String viewId) could possibly be the culprit.

In particular the following line looks suspicious:

// org.jboss.seam.mock.MockViewHandler.getActionURL
 return contextPath + servletPath + viewId;

before it is reached the values of these variables are as follows:
contextPath == /seam-discs
servletPath == /artist.seam
viewId == /error.xhtml

Thus, "/seam-discs/artist.seam/error.xhtml" is returned by MockViewHandler.getActionURL



But maybe this result gets processed later and hence is really intended.