Hi Leo, all advantages and disadvantages are 100% fine for me but i don't like this one:
- Third party libraries needs to be compatible with the technique. What changes are required for third party components? Would it be possible that components are still 100% compatible with mojarra without changes? Regards, Thomas 2013/11/23 Leonardo Uribe <[email protected]> > Hi > > Some time ago it was discussed under these topics: > > [core][proposal] JSF View Pooling (going beyond JSF Stateless Mode) > > http://markmail.org/message/54rb3aphc6txwzbr > > [core][discuss] Is it worth to include Stateless JSF / View Pooling > concept into MyFaces? > > http://markmail.org/message/pc42cbcvvhlboivb > > The advantages and disadvantages of include view pooling into MyFaces. > > With the recent work done in: > > https://issues.apache.org/jira/browse/MYFACES-3825 > > And other tests done, some assumptions over this topic have changed. For > example: > > Before: > > - The use ui:param uses EL VariableResolver, makes the view non poolable, > because the ValueExpression instances are not stateless in this case. > > After: > > EL expressions under "alwaysRecompile" mode can be cacheable and it was > verified that no information related to the state is included into EL > expressions, so if two component trees were created by the same > facelet under the same conditions, they will have both the same > EL expressions. > > Before: > > - It is difficult to keep the code synchronized between versions of JSF, > because each concept related to view handling affects how the view pool > works. > > After: > > Now is the right time to include it, because we are now in JSF 2.2, and > all new features should go there. > > Before: > > - It could create memory fragmentation, making garbage collection slower. > - Higher memory footprint. > > After: > > The view pool holds the views using a soft reference, so the garbage > collector will be able to collect the views at any time. There is no need > to worry about memory fragmentation. > > The increase of memory use due to the view pool is not significant compared > with the savings of memory usage in general. > > Before: > > - Detection technique to enable this optimization is not 100% fail-safe. > > After: > > It is still true, because some components needs to be compatible with the > technique, but with MYFACES-3825 if all components in a view are compatible > we can be sure that the view is poolable. > > The current disadvantage list is this: > > - Detection technique to enable this optimization is not 100% fail-safe. > - Third party libraries needs to be compatible with the technique. > - Complexity can be too high, (but we can reduce the burden doing some > proper documentation). > > Do the advantages justify the introduction of this concept? In my personal > opinion probably yes by two main reasons: > > - It improves significantly the time spent in ajax request. > - If all components in a view are compatible, that view is poolable. > > Should we include it in MyFaces 2.2.x? why not? after all, it is something > that can be optional. For example, libraries like Trinidad provides > org.apache.myfaces.trinidad. > CACHE_VIEW_ROOT web config param. This feature > is something that aims to the same and it is even better. > > I think it is worth to give another round to this topic and see what > happens. > > regards, > > Leonardo Uribe > > http://www.irian.at > > Your JSF/JavaEE powerhouse - > JavaEE Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > ___________________________ > > Don't miss it: > > CONFESS_2014@ JavaLand 2014 <http://www.javaland.eu/en/javaland-2014.html> > > ____________________________ >
