You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Gerhard Petracek (JIRA)" <de...@myfaces.apache.org> on 2013/09/30 13:56:24 UTC

[jira] [Reopened] (MYFACES-3587) Not existing viewId will not be handled

     [ https://issues.apache.org/jira/browse/MYFACES-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gerhard Petracek reopened MYFACES-3587:
---------------------------------------


we have to fix this issue.

if the view-id is null (for whatever reason), it isn't ok to just use the JspViewDeclarationLanguageStrategy which can lead to strange errors like java.lang.NoClassDefFoundError: javax/servlet/jsp/jstl/core/Config - just because this class is needed for this strategy.

usually modern jsf-applications don't even have a single jsp-page. backward-compatibility can't be a blocker for it, since "no view-id" doesn't mean that there is a jsp for it.

> Not existing viewId will not be handled
> ---------------------------------------
>
>                 Key: MYFACES-3587
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3587
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: General
>    Affects Versions: 2.1.8
>         Environment: Jetty/Tomcat, JUEL, CODI, ExtVal
>            Reporter: Thomas Andraschko
>            Assignee: Leonardo Uribe
>
> If i call a page, which does not exist, following exceptions occurs: Cannot reset buffer after response has been committed.
> After digging deeper into this problem, i found out that getViewHandlerSupport()#calculateViewId returns null and the JspViewDeclarationLanguageStrategy will be used -> 
> Cannot reset buffer after response has been committed. 
> occurs.
> I added a null check for the logicalViewId in RestoreViewExecutor#execute to call HttpServletResponse#sendError.
> It does not work as expected because it just renders the errorPage and no redirect will be done.
> Why there is not such null check?
> Is it possible to add this check and redirect to the web.xml defined 404 or common error page? Or should it use the ErrorHandler?



--
This message was sent by Atlassian JIRA
(v6.1#6144)