Re: [Trinidad] using t:saveState

[Renzo Tomaselli]

Matthia, I apologize for the font. Thunderbird updated itself to 1.5.0.9 this morning, then it seems to set font size to xx-large, while appearing normal here. Current text is set to small. Concerning state restoring: from the debugger I noticed that when restoring *doesn't* work, in method org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView() we have:       _LOG.fine("Successfully found view state for token {0}", token);       UIViewRoot root = viewState.popRoot(context); // bug 4712492       if (root != null)       {         _LOG.finer("UIViewRoot for token {0} already exists. Bypassing restoreState", token);         return root;   // <----- returns here       } method returns there, thus skipping processRestoreState. On the other hand, when it restores correctly, this method returns after calling processRestoreState a few lines further, which does proper state restoring. It seems that a kind of cache hit based on retrieved token prevents full restoring. Just a guess. Regarding the TrinidadFilter: I can see it on the stack (doFilter, _doFilterImpl, _invokeDoFilter, etc.) however the log warning is there. My web.xml is: <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://java.sun.com/xml/ns/j2ee"     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.4"     xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">     <display-name>Conaxo axxento publisher</display-name>     <description>Conaxo experiments</description>     <!-- Trinidad -->   <!-- Trinidad has its own ViewHandler, which is a "decorating"        view handler - for example, it needs to wrap methods like renderView()        to perform some extra pre- and post-handling.  Facelets, on the other        hand, is more of a true ViewHandler - it actually implements        renderView() (yeah, it decorates too, but forget about that        for a second).  As a result, the world is a better place if        the Trinidad ViewHandler runs around the Facelets ViewHandler.        But since Facelets is registered in WEB-INF/faces-config.xml,        and Trinidad's is registered from META-INF/faces-config.xml in its        JAR, exactly the opposite happens as per the JSF spec.        Hence, the following config parameter, which Trinidad        exposes to allow pushing a ViewHandler inside        of ours.  FWIW, you retain the entire delegation stack -        just flipped around a bit - so that Facelets still decorates        the standard ViewHandler, and therefore you've still got        JSP support.   -->   <context-param>     <param-name>org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER</param-name>     <param-value>com.sun.facelets.FaceletViewHandler</param-value>   </context-param>   <!-- Trinidad by default uses an optimized client-side state saving        mechanism. To disable that, uncomment the following -->   <!--context-param>     <param-name>org.apache.myfaces.trinidad.CLIENT_STATE_METHOD</param-name>     <param-value>all</param-value>   </context-param-->   <!-- Trinidad also supports an optimized strategy for caching some    view state at an application level, which significantly improves    scalability.  However, it makes it harder to develop (updates to    pages will not be noticed until the server is restarted), and in    some rare cases cannot be used for some pages (see Trinidad    documentation for more information) -->   <context-param>     <param-name>org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE</param-name>     <param-value>false</param-value>   </context-param>   <!-- If this parameter is enabled, Trinidad will automatically        check the modification date of your JSPs, and discard saved        state when they change;  this makes development easier,        but adds overhead that should be avoided when your application        is deployed -->   <context-param>     <param-name>org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION</param-name>     <param-value>true</param-value>   </context-param>   <!-- Enables Change Persistence at a session scope.  By default,        Change Persistence is entirely disabled. The ChangeManager is        an API, which can persist component modifications (like,        is a showDetail or tree expanded or collapsed). For providing        a custom Change Persistence implementation inherit from the        Trinidad API's ChangeManager class. As the value you have        to use the fullqualified class name. -->   <context-param>     <param-name>org.apache.myfaces.trinidad.CHANGE_PERSISTENCE</param-name>     <param-value>session</param-value>   </context-param>     <!-- facelets  -->     <context-param>         <param-name>facelets.REFRESH_PERIOD</param-name>         <param-value>2</param-value>     </context-param>     <context-param>         <param-name>facelets.DEVELOPMENT</param-name>         <param-value>true</param-value>     </context-param>       <context-param>         <param-name>facelets.LIBRARIES</param-name>         <param-value>             /tags/tomahawk.taglib.xml;             /tags/conaxo.taglib.xml         </param-value>     </context-param>     <!-- Use client-side state saving.  In Trinidad, it is an         optimized, token-based mechanism that is almost always a         better choice than the standard JSF server-side state saving. -->     <context-param>         <param-name>javax.faces.STATE_SAVING_METHOD</param-name>         <param-value>client</param-value>     </context-param>         <context-param>         <param-name>javax.faces.DEFAULT_SUFFIX</param-name>         <param-value>.xhtml</param-value>     </context-param>     <!-- private  -->     <context-param>         <param-name>javax.faces.CONFIG_FILES</param-name>         <param-value>             /WEB-INF/login-config.xml,             /WEB-INF/logout-config.xml,             /WEB-INF/dbList-config.xml,             /WEB-INF/docBrowser-config.xml,             /WEB-INF/dbTree-config.xml,             /WEB-INF/result-config.xml,             /WEB-INF/navigator.xml,         </param-value>     </context-param>     <context-param>         <param-name>user</param-name>         <param-value>Tomarenz</param-value>     </context-param>     <context-param>         <param-name>domain</param-name>         <param-value>Atlantis</param-value>     </context-param>     <context-param>         <param-name>host</param-name>         <param-value>Renzo</param-value>     </context-param>     <context-param>         <param-name>loginType</param-name>         <param-value>s</param-value>     </context-param>   <filter>     <filter-name>trinidad</filter-name>     <filter-class>org.apache.myfaces.trinidad.webapp.TrinidadFilter</filter-class>   </filter>     <!-- Tomahawk filter  -->     <filter>         <filter-name>MyFacesExtensionsFilter</filter-name>         <filter-class>org.apache.myfaces.webapp.filter.ExtensionsFilter</filter-class>         <init-param>             <param-name>maxFileSize</param-name>             <param-value>20m</param-value>         </init-param>     </filter>   <filter-mapping>     <filter-name>trinidad</filter-name>     <servlet-name>faces</servlet-name>   </filter-mapping>         <!-- extension mapping for adding <script/>, <link/>, and other resource tags to JSF-pages  -->     <filter-mapping>         <filter-name>MyFacesExtensionsFilter</filter-name>         <!-- servlet-name must match the name of your javax.faces.webapp.FacesServlet entry -->         <servlet-name>faces</servlet-name>     </filter-mapping>         <!-- extension mapping for serving page-independent resources (_javascript_, stylesheets, images, etc.)  -->     <filter-mapping>         <filter-name>MyFacesExtensionsFilter</filter-name>         <url-pattern>/faces/myFacesExtensionResource/*</url-pattern>     </filter-mapping>       <!-- resource loader servlet -->       <servlet>         <servlet-name>resources</servlet-name>         <servlet-class>org.apache.myfaces.trinidad.webapp.ResourceServlet</servlet-class>       </servlet>       <servlet>        <servlet-name>faces</servlet-name>        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>        <load-on-startup>1</load-on-startup>     </servlet>             <servlet-mapping>         <servlet-name>resources</servlet-name>         <url-pattern>/adf/*</url-pattern>       </servlet-mapping>     <servlet-mapping>       <servlet-name>faces</servlet-name>       <url-pattern>*.faces</url-pattern>     </servlet-mapping>  </web-app> Matthias Wessendorf wrote: Renzo, can you please reduce your font size ? :) Hard to read in gmail :) Regarding the verifyFilterIsInstalled method... perhaps the TrinidadFilter is not *ordered* in the "right" way? I have them listed in web.xml before the servlets (and their mapping) Perhaps you wonder why the TrinidadFilterImpl present. That is because it is added via the Meta-inf/service facility.