incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Renzo Tomaselli <>
Subject Re: [Trinidad] using t:saveState
Date Wed, 20 Dec 2006 17:56:14 GMT
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(
            // 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),

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 
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 <> 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

View raw message