incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Renzo Tomaselli <renzo.tomase...@tecnotp.it>
Subject Re: [Trinidad] using t:saveState
Date Wed, 20 Dec 2006 17:28:15 GMT
Matthias, I placed the param below at the beginning of web.xml, but 
things run as before, e.g. viewState.popRoot(context) gets called while 
restoring every view.
I could not spot where this caching optimization should depend on a 
parameter.
Where can I control that flag from sources and how can I turn Trinidad 
logging to a finer grain ?
Btw, I noticed another misbehavior which might be related to wrong view 
caching. I have a page with a section which is rendered according to a 
show/hide button.
It happens sometime that - with details hidden - bean setters are called 
for actually unrendered  components, much like having a mismatch between 
actual view and the cache.  New value passed in is null  though,  hence  
quite a number of troubles.
-- Renzo

Matthias Wessendorf wrote:
> 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.
>> >
>> >
>> >
>>
>
>

Mime
View raw message