You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-user@incubator.apache.org by Renzo Tomaselli <re...@tecnotp.it> on 2006/12/20 12:10:04 UTC
[Trinidad] using t:saveState
Hi, back again to adapt an application to Trinidad.
I have a page using Tomahawk t:saveState to save a string across requests.
This page contains also a t:tree2 component. Now if I perform any action on
the tree - such as clicking on nodes or expanding branches - my debugger shows
that state is not restored. Other setters are regularly invoked.
But if I use the back button on the browser and I click again on the tree,
state is restored. It works like a flip-flop, once out of two.
I don't know the magics of state saving with Trinidad, I guess things depend
on a hidden element attached to forms, such as:
<input type="hidden" name="org.apache.myfaces.trinidad.faces.STATE"
value="!23efc8f3">
Also I noticed that sources of rendered html page are the same, both when next
click will work and when it will not.
Needless to say, things used to work fine until Trinindad entered my web.xml.
Also I noticed that Tomcat logout still reports:
20-dic-2006 12.42.53
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl
verifyFilterIsInstalled
WARNING: The TrinidadFilter has not been installed. Apache Trinidad requires
this filter for proper execution.
but my web.xml contains:
<filter>
<filter-name>trinidad</filter-name>
<filter-class>org.apache.myfaces.trinidad.webapp.TrinidadFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>trinidad</filter-name>
<servlet-name>faces</servlet-name>
</filter-mapping>
Any suggestion is welcome. I can ispect/debug sources if provided with some
pointers about state restoring.
\-- Renzo
Re: [Trinidad] using t:saveState
Posted by Matthias Wessendorf <ma...@apache.org>.
here is another web.xml;
using tomahawk and trinidad in one project
<?xml version = '1.0' encoding = 'ISO-8859-1'?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
<context-param>
<param-name>org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER</param-name>
<param-value>com.sun.facelets.FaceletViewHandler</param-value>
</context-param>
<!-- Use Documents Saved as *.xhtml -->
<context-param>
<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
<param-value>.xhtml</param-value>
</context-param>
<context-param>
<param-name>facelets.LIBRARIES</param-name>
<param-value>/WEB-INF/tomahawk.taglib.xml</param-value>
</context-param>
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.trinidad.CHANGE_PERSISTENCE</param-name>
<param-value>session</param-value>
</context-param>
<filter>
<filter-name>trinidad</filter-name>
<filter-class>org.apache.myfaces.trinidad.webapp.TrinidadFilter</filter-class>
</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>
<!-- Listener, to allow Jetty serving MyFaces apps -->
<listener>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
<!-- Faces Servlet -->
<servlet>
<servlet-name>faces</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>
<!-- resource loader servlet -->
<servlet>
<servlet-name>resources</servlet-name>
<servlet-class>org.apache.myfaces.trinidad.webapp.ResourceServlet</servlet-class>
</servlet>
<!-- Faces Servlet Mappings -->
<servlet-mapping>
<servlet-name>faces</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>resources</servlet-name>
<url-pattern>/adf/*</url-pattern>
</servlet-mapping>
</web-app>
On 12/20/06, Matthias Wessendorf <ma...@apache.org> 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.
>
> Here is a web.xml of one of my projects, using Shale, Trinidad,
> facelets and myfaces
>
> <?xml version = '1.0' encoding = 'ISO-8859-1'?>
> <web-app xmlns="http://java.sun.com/xml/ns/j2ee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
> version="2.4">
>
> <context-param>
> <param-name>org.apache.myfaces.trinidadinternal.DISABLE_CONTENT_COMPRESSION</param-name>
> <param-value>false</param-value>
> </context-param>
>
> <context-param>
> <param-name>org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER</param-name>
> <param-value>com.sun.facelets.FaceletViewHandler</param-value>
> </context-param>
>
> <!-- Use Documents Saved as *.xhtml -->
> <context-param>
> <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
> <param-value>.xhtml</param-value>
> </context-param>
>
>
> <context-param>
> <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
> <param-value>client</param-value>
> </context-param>
>
> <context-param>
> <param-name>org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE</param-name>
> <param-value>false</param-value>
> </context-param>
>
> <context-param>
> <param-name>org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION</param-name>
> <param-value>true</param-value>
> </context-param>
>
> <context-param>
> <param-name>org.apache.myfaces.trinidad.CHANGE_PERSISTENCE</param-name>
> <param-value>session</param-value>
> </context-param>
>
> <!-- Commons Chain Configuration Resources -->
> <context-param>
> <param-name>org.apache.commons.chain.CONFIG_WEB_RESOURCE</param-name>
> <param-value>/WEB-INF/chain-config.xml</param-value>
> </context-param>
>
> <!-- Shale Application Controller Filter -->
> <filter>
> <filter-name>shale</filter-name>
> <filter-class>
> org.apache.shale.application.faces.ShaleApplicationFilter
> </filter-class>
> </filter>
>
> <filter>
> <filter-name>trinidad</filter-name>
> <filter-class>org.apache.myfaces.trinidad.webapp.TrinidadFilter</filter-class>
> </filter>
>
> <!-- Shale Application Controller Filter Mapping -->
> <filter-mapping>
> <filter-name>shale</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
> <filter-mapping>
> <filter-name>trinidad</filter-name>
> <servlet-name>faces</servlet-name>
> </filter-mapping>
>
> <!-- Listener, to allow Jetty serving MyFaces apps -->
> <!--listener>
> <listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
> </listener-->
>
> <!-- Commons Chain Configuration Listener -->
> <listener>
> <listener-class>
> org.apache.commons.chain.web.ChainListener
> </listener-class>
> </listener>
>
>
> <!-- Faces Servlet -->
> <servlet>
> <servlet-name>faces</servlet-name>
> <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
> </servlet>
>
> <!-- resource loader servlet -->
> <servlet>
> <servlet-name>resources</servlet-name>
> <servlet-class>org.apache.myfaces.trinidad.webapp.ResourceServlet</servlet-class>
> </servlet>
>
> <!-- Faces Servlet Mappings -->
> <servlet-mapping>
> <servlet-name>faces</servlet-name>
> <url-pattern>*.faces</url-pattern>
> </servlet-mapping>
>
> <servlet-mapping>
> <servlet-name>resources</servlet-name>
> <url-pattern>/adf/*</url-pattern>
> </servlet-mapping>
>
> </web-app>
>
> -Matthias
>
> On 12/20/06, Renzo Tomaselli <re...@tecnotp.it> wrote:
> >
> > Hi, back again to adapt an application to Trinidad.
> > I have a page using Tomahawk t:saveState to save a string across requests.
> > This page contains also a t:tree2 component. Now if I perform any action on
> > the tree - such as clicking on nodes or expanding branches - my debugger
> > shows that state is not restored. Other setters are regularly invoked.
> > But if I use the back button on the browser and I click again on the tree,
> > state is restored. It works like a flip-flop, once out of two.
> > I don't know the magics of state saving with Trinidad, I guess things
> > depend on a hidden element attached to forms, such as:
> >
> > <input type="hidden"
> > name="org.apache.myfaces.trinidad.faces.STATE"
> > value="!23efc8f3">
> >
> > Also I noticed that sources of rendered html page are the same, both when
> > next click will work and when it will not.
> > Needless to say, things used to work fine until Trinindad entered my
> > web.xml.
> > Also I noticed that Tomcat logout still reports:
> >
> > 20-dic-2006 12.42.53
> > org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl
> > verifyFilterIsInstalled
> > WARNING: The TrinidadFilter has not been installed. Apache Trinidad
> > requires this filter for proper execution.
> >
> > but my web.xml contains:
> >
> > <filter>
> > <filter-name>trinidad</filter-name>
> >
> > <filter-class>org.apache.myfaces.trinidad.webapp.TrinidadFilter</filter-class>
> > </filter>
> >
> > <filter-mapping>
> > <filter-name>trinidad</filter-name>
> > <servlet-name>faces</servlet-name>
> > </filter-mapping>
> >
> > Any suggestion is welcome. I can ispect/debug sources if provided with some
> > pointers about state restoring.
> > -- Renzo
> >
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [Trinidad] using t:saveState
Posted by Matthias Wessendorf <ma...@apache.org>.
quick note regarding the Filter:
> Regarding the TrinidadFilter: I can see it on the stack (doFilter,
> _doFilterImpl, _invokeDoFilter, etc.) however the log warning is there. My
all these are method of the
TrinidadFilterImpl
(pack: org.apache.myfaces.trinidadinternal.webapp)
not of the TrinidadFilter
(pack: org.apache.myfaces.trinidad.webapp)
I tried your web.xml in my environment (Jetty6)
works fine!
(I don't get the warning)
-M
Re: [Trinidad] using t:saveState
Posted by Renzo Tomaselli <re...@tecnotp.it>.
Great, Adam.
Now boh state restoring and h:commandButton work fine.
Thanks -- Renzo
Adam Winer wrote:
> YIKES! Thanks for pointing that glitch out. *Fixed*.
>
> Thanks,
> Adam
>
>
> On 12/20/06, Renzo Tomaselli
> [<re...@tecnotp.it>](mailto:renzo.tomaselli@tecnotp.it) wrote:
>
>
>> After some debugging, I noticed that the suggested parameter cannot
> work, since we have (in StateManagerImpl.saveSerializedView()):
>
> // FIXME: pageState is never read
> PageState pageState = new PageState(
> context,
> structure,
> state,
> // Save the view root into the page state as a transient
> // if this feature has not been disabled
> _useViewRootCache(context) ? root : null);
>
> token = cache.addNewEntry(new PageState(context, structure,
> state, root),
> stateMap);
>
> thus a valid root to cache is always passed in to PageState constructor,
> no matter the value of useViewRootCache, which is set according to the
> parameter.
> Indeed the FIXME says all.
> \-- Renzo
>
> Renzo Tomaselli wrote:
> > 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 [<aw...@gmail.com>](mailto: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
> >
>
>
>
>
>
>
Re: [Trinidad] using t:saveState
Posted by Adam Winer <aw...@gmail.com>.
YIKES! Thanks for pointing that glitch out. *Fixed*.
Thanks,
Adam
On 12/20/06, Renzo Tomaselli <re...@tecnotp.it> wrote:
> After some debugging, I noticed that the suggested parameter cannot
> work, since we have (in StateManagerImpl.saveSerializedView()):
>
> // FIXME: pageState is never read
> PageState pageState = new PageState(
> context,
> structure,
> state,
> // Save the view root into the page state as a transient
> // if this feature has not been disabled
> _useViewRootCache(context) ? root : null);
>
> token = cache.addNewEntry(new PageState(context, structure,
> state, root),
> stateMap);
>
> thus a valid root to cache is always passed in to PageState constructor,
> no matter the value of useViewRootCache, which is set according to the
> parameter.
> Indeed the FIXME says all.
> -- Renzo
>
> Renzo Tomaselli wrote:
> > 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 <aw...@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
> >
>
Re: [Trinidad] using t:saveState
Posted by Renzo Tomaselli <re...@tecnotp.it>.
After some debugging, I noticed that the suggested parameter cannot
work, since we have (in StateManagerImpl.saveSerializedView()):
// FIXME: pageState is never read
PageState pageState = new PageState(
context,
structure,
state,
// Save the view root into the page state as a transient
// if this feature has not been disabled
_useViewRootCache(context) ? root : null);
token = cache.addNewEntry(new PageState(context, structure,
state, root),
stateMap);
thus a valid root to cache is always passed in to PageState constructor,
no matter the value of useViewRootCache, which is set according to the
parameter.
Indeed the FIXME says all.
-- Renzo
Renzo Tomaselli wrote:
> 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 <aw...@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
>
Re: [Trinidad] using t:saveState
Posted by Renzo Tomaselli <re...@tecnotp.it>.
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 <aw...@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 <re...@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.
>> >
>> >
>> >
>>
>
>
Re: [Trinidad] using t:saveState
Posted by Matthias Wessendorf <ma...@apache.org>.
Adam,
can you nail that to tomahawks jira?
thx,
On 12/20/06, Adam Winer <aw...@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 <re...@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
Re: [Trinidad] using t:saveState
Posted by Adam Winer <aw...@gmail.com>.
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 <re...@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.
>
>
>
Re: [Trinidad] using t:saveState
Posted by Renzo Tomaselli <re...@tecnotp.it>.
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"](http://java.sun.com/xml/ns/j2ee)
xmlns:xsi=["http://www.w3.org/2001/XMLSchema-instance"](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"](http://java.sun.com/xml/ns/j2eehttp://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.
>
>
>
Re: [Trinidad] using t:saveState
Posted by Matthias Wessendorf <ma...@apache.org>.
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.
Here is a web.xml of one of my projects, using Shale, Trinidad,
facelets and myfaces
<?xml version = '1.0' encoding = 'ISO-8859-1'?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
<context-param>
<param-name>org.apache.myfaces.trinidadinternal.DISABLE_CONTENT_COMPRESSION</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER</param-name>
<param-value>com.sun.facelets.FaceletViewHandler</param-value>
</context-param>
<!-- Use Documents Saved as *.xhtml -->
<context-param>
<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
<param-value>.xhtml</param-value>
</context-param>
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.trinidad.CHANGE_PERSISTENCE</param-name>
<param-value>session</param-value>
</context-param>
<!-- Commons Chain Configuration Resources -->
<context-param>
<param-name>org.apache.commons.chain.CONFIG_WEB_RESOURCE</param-name>
<param-value>/WEB-INF/chain-config.xml</param-value>
</context-param>
<!-- Shale Application Controller Filter -->
<filter>
<filter-name>shale</filter-name>
<filter-class>
org.apache.shale.application.faces.ShaleApplicationFilter
</filter-class>
</filter>
<filter>
<filter-name>trinidad</filter-name>
<filter-class>org.apache.myfaces.trinidad.webapp.TrinidadFilter</filter-class>
</filter>
<!-- Shale Application Controller Filter Mapping -->
<filter-mapping>
<filter-name>shale</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>trinidad</filter-name>
<servlet-name>faces</servlet-name>
</filter-mapping>
<!-- Listener, to allow Jetty serving MyFaces apps -->
<!--listener>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener-->
<!-- Commons Chain Configuration Listener -->
<listener>
<listener-class>
org.apache.commons.chain.web.ChainListener
</listener-class>
</listener>
<!-- Faces Servlet -->
<servlet>
<servlet-name>faces</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>
<!-- resource loader servlet -->
<servlet>
<servlet-name>resources</servlet-name>
<servlet-class>org.apache.myfaces.trinidad.webapp.ResourceServlet</servlet-class>
</servlet>
<!-- Faces Servlet Mappings -->
<servlet-mapping>
<servlet-name>faces</servlet-name>
<url-pattern>*.faces</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>resources</servlet-name>
<url-pattern>/adf/*</url-pattern>
</servlet-mapping>
</web-app>
-Matthias
On 12/20/06, Renzo Tomaselli <re...@tecnotp.it> wrote:
>
> Hi, back again to adapt an application to Trinidad.
> I have a page using Tomahawk t:saveState to save a string across requests.
> This page contains also a t:tree2 component. Now if I perform any action on
> the tree - such as clicking on nodes or expanding branches - my debugger
> shows that state is not restored. Other setters are regularly invoked.
> But if I use the back button on the browser and I click again on the tree,
> state is restored. It works like a flip-flop, once out of two.
> I don't know the magics of state saving with Trinidad, I guess things
> depend on a hidden element attached to forms, such as:
>
> <input type="hidden"
> name="org.apache.myfaces.trinidad.faces.STATE"
> value="!23efc8f3">
>
> Also I noticed that sources of rendered html page are the same, both when
> next click will work and when it will not.
> Needless to say, things used to work fine until Trinindad entered my
> web.xml.
> Also I noticed that Tomcat logout still reports:
>
> 20-dic-2006 12.42.53
> org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl
> verifyFilterIsInstalled
> WARNING: The TrinidadFilter has not been installed. Apache Trinidad
> requires this filter for proper execution.
>
> but my web.xml contains:
>
> <filter>
> <filter-name>trinidad</filter-name>
>
> <filter-class>org.apache.myfaces.trinidad.webapp.TrinidadFilter</filter-class>
> </filter>
>
> <filter-mapping>
> <filter-name>trinidad</filter-name>
> <servlet-name>faces</servlet-name>
> </filter-mapping>
>
> Any suggestion is welcome. I can ispect/debug sources if provided with some
> pointers about state restoring.
> -- Renzo
>
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com