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 <[EMAIL PROTECTED]> 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.
