myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jakob Korherr (JIRA)" <...@myfaces.apache.org>
Subject [jira] Resolved: (MYFACES-2641) Use the application's ViewHandler to create the view in FaceletViewMetadata
Date Fri, 02 Apr 2010 15:48:32 GMT

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

Jakob Korherr resolved MYFACES-2641.
------------------------------------

       Resolution: Fixed
    Fix Version/s: 2.0.0-beta-4

> Use the application's ViewHandler to create the view in FaceletViewMetadata
> ---------------------------------------------------------------------------
>
>                 Key: MYFACES-2641
>                 URL: https://issues.apache.org/jira/browse/MYFACES-2641
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: JSR-314
>    Affects Versions: 2.0.0-beta-3
>         Environment: MyFaces core trunk + Trinidad jsf2_ajax.3 branch
>            Reporter: Jakob Korherr
>            Assignee: Jakob Korherr
>             Fix For: 2.0.0-beta-4
>
>
> When the current VDL is FaceletViewDeclarationLanguage, the ViewMetadata impl for facelets
(FaceletViewMetadata) is used to create the view the following way in RestoreViewExecutor:
> viewRoot = metadata.createMetadataView(facesContext);
> The method createMetadataView() then directly invokes createView() in the surrounding
class (FaceletViewDeclarationLanguage) to create the view. This works for most cases, because
normally when using FaceletViewMetadata as the ViewMetadata impl, FaceletViewDeclarationLanguage
will be the VDL and the default ViewHandler implementation only redirects the call to createView()
to the right VDL.
> However in Trinidad's AJAX branch (jsf2_ajax.3) another ViewHandler implementation is
used (org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl), which does some work
before calling createView() on the right VDL. This work is storing the last modified date
of the accessed file to discover any modifications of it.
> If we now not call createView() on Trinidad's ViewHandler impl but directly on the FaceletVDL,
this work will not happen and the last modified date will not be available for the next request.
So the next request, which will be a postback to this view, has no last modified information
about the requested view and thus it will throw a ViewExpiredException like this one:
> javax.faces.application.ViewExpiredException: /index.jspxNo saved view
> state could be found for the view identifier: /index.jspx
>        at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:114)
>        at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:138)
>        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88)
>        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)
>        at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
>        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
>        at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247)
>        at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157)
>        at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
>        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
>        at org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97)
>        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
>        at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
>        at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>        at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
>        at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
>        at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
>        at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
>        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>        at org.mortbay.jetty.Server.handle(Server.java:326)
>        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536)
>        at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930)
>        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
>        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
>        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
>        at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
>        at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> The related thread to this issue from the mailing list can be found here: http://www.mail-archive.com/dev@myfaces.apache.org/msg44985.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message