myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Andraschko <andraschko.tho...@gmail.com>
Subject Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x
Date Sun, 24 Nov 2013 02:21:33 GMT
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 <lu4242@gmail.com>

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

Mime
View raw message