incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Wessendorf" <mat...@apache.org>
Subject Re: [Trinidad] using t:saveState
Date Wed, 20 Dec 2006 16:46:56 GMT
Adam,

can you nail that to tomahawks jira?

thx,


On 12/20/06, Adam Winer <awiner@gmail.com> wrote:
> A magic configuration option should solve the problem
>
>     <context-param>
>         <param-name>org.apache.myfaces.trinidad.CACHE_VIEW_ROOT</param-name>
>         <param-value>false</param-value>
>     </context-param>
>
> The optimization in StateManagerImpl is very significant, but it
> *does* break t:saveState - since when it is in effect, we can skip
> processRestoreState() altogether.  It'd be a Good Thing if t:saveState
> was able to deal with StateManagers that include this optimization.
>
> -- Adam
>
>
> On 12/20/06, Renzo Tomaselli <renzo.tomaselli@tecnotp.it> wrote:
> >
> >  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.
> >
> >
> >
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Mime
View raw message