[core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Leonardo Uribe <lu...@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>

____________________________

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Leonardo Uribe <lu...@gmail.com>]

Hi

If no state saving is set, the default is "server". As I said before, the
component tree and the calculated state are two different things and there
is not any relationship. Really the separation of these two concepts and
the introduction of a view pool as an effective way to keep memory usage
low is something new, that no other web framework is able to do properly
(unless in my knowledge).

regards,

Leonardo Uribe


2013/12/16 Dora Rajappan <do...@yahoo.com>

>
> Thanks for explaining viewpool and viewstate. I will go through the code
> later and understand.
> I was wondering what happens when state saving method param is not set. I
> got your point it that the state saving algorithm is performed and when its
> not mentioned whether it state saving method is client/server its assumed
> to save views in session and that might not have changed with view pool
> else it can affect maximum sequential views in session. I  have to go
> through the code to follow that.
>
> Regards,
> Dora Rajappan.
>
>
>   On Saturday, December 14, 2013 3:53 AM, Leonardo Uribe <lu...@gmail.com>
> wrote:
>  Hi
>
> "... When views are not transient and view pool enabled with no state
> saving or serialisation enabled ..."
>
>
> I don't get anything about what you mean. But I understand that the topic
> of state management is really, really complex, and has been a misunderstood
> problem for years in the world of web application development. So I'm going
> to clarify your confusion:
>
> 1. If the view is "transient" then the view is considered "stateless". No
> state saving is performed over stateless views, but since the view pool
> reuses state saving algorithm the view is not reused by the view pool
> algorithm.
> 2. If the view is not "transient", state saving algorithm is performed.
> 3. You CAN'T disable state saving. There is no web config parameter to do
> that, not to mention that a param to do that would be completely pointless,
> because the whole point of JSF is solve with the state problem to make
> applications in the web easier.
> 4. StateManagementStrategy deals with the problem of how the vdl
> calculates the state, but it is not responsible of store the state.
> 5. ResponseStateManger deals with two problems.
> - Restore and save the state somewhere. In myfaces we included some
> classes for that: org.apache.myfaces.application.StateCacheFactory,
> org.apache.myfaces.application.StateCache. There are two basic
> implementations: ServerSideStateCacheImpl and ClientSideStateCacheImpl, but
> it can be more and it has been proposed to include a mixed mode. There is
> still work and some discussions to do in that part but they are not
> prioritary for now, but in the past it has been a controversial matter. The
> solution we have right now works just fine.
> - Modify the response to include the necessary information to save and
> restore the state. This is done usually writing the javax.faces.ViewState
> and the javax.faces.ClientWindow.
> 6. StateManagementStrategy is affected by the view pool because in the
> calculation step we store or retrieve a view from the pool, but ResponseStateManger
> is not affected by the pool. Take a look at the code first.
>
> regards,
>
> Leonardo Uribe
>
>
>
>
> 2013/12/13 Dora Rajappan <do...@yahoo.com>
>
>
> Hi Leonardo,
>
>  Thanks for explaining that the statemanagementstrategy is unaffected by
> the view pooling.
>  When views are not transient and view pool enabled with no state saving
> or serialisation enabled, the view pool processing remain the same and the
> state is saved in session.
>
> Regards
> Dora Rajappan.
>
>
>   On Friday, December 13, 2013 8:17 PM, Leonardo Uribe <lu...@gmail.com>
> wrote:
>  Hi
>
> 2013/12/13 Dora Rajappan <do...@yahoo.com>
>
> Not bad +1 for view pool.
>
> When VIEW_POOL_ENABLED the param
> org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION<http://myfaces.apache.org/core21/myfaces-impl/webconfig.html#org_apache_myfaces_NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION> is
> not considered and not required to set.
> org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION<http://myfaces.apache.org/core21/myfaces-impl/webconfig.html#org_apache_myfaces_NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION> is
> valid for state saving client/server.
>
>
> View Pooling is all about "efficient memory management". The state saving
> algorithm is another different thing, and the view pool does not affect the
> way how state saving restoring works. I unfortunately have to say that your
> comment does not have sense. This feature is something new, ouside JSF 2.2
> spec but proposed to be included in MyFaces 2.2. What we are doing here and
> we have done for more than 1 year is discuss and justify the addition of
> this feature.
>
> regards,
>
> Leonardo Uribe
>
>
>
>
> Regards,
> Dora Rajappan.
>
>
>   On Friday, December 13, 2013 2:21 PM, Thomas Andraschko <
> andraschko.thomas@gmail.com> wrote:
>  Cool leo! Thanks for your effort :)
>
>
>
> 2013/12/13 Leonardo Uribe <lu...@gmail.com>
>
> Hi
>
> Finally the code for View Pooling has been comitted. After some
> performance
> tests with the know demo application, it has been confirmed the following
> improvements:
>
> - A reduction of 25% of the transient memory used, which means a lot less
> memory is used and it is used at a slower pace. It also means less GC calls
> and a better CPU usage.
> - An improvement of 9% over throughput for non ajax requests.
> - An improvement from 9% to 30% or even more for ajax request, according to
> the tree size.
>
> These improvements are very good and justify the use of the view pool. But
> in order to be transparent and open with the community we have not
> explained
> the details behind how the view pool really works. So, I created a blog
> about this topic that I hope to move it into MyFaces documentation once
> a release of 2.2.0 is out (we have some pending work to do in the
> documentation area, so I hope to do everything in one step).
>
> http://lu4242.blogspot.com/2013/12/view-pooling-in-jsf-22-using-apache.html
>
> The blog summarize all information about this topic, its origins,
> the reasons behind them and the solution proposed, so we can discuss it
> later
> if there is any doubt or critic about it. It is a long story but this is
> something we need to document properly.
>
> regards,
>
> Leonardo Uribe
>
>
> 2013/12/9 Leonardo Uribe <lu...@gmail.com>
>
> Hi
>
> It seems we have an inconsistency between what was proposed to enable the
> view pool and the inclusion of the new parameter.
>
> At start we have this:
>
> org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in
> the app, by default false)
>
> But if we use an attribute in f:view like "oamEnableViewPool", aiming to
> select the views that will use the pool, the previous param does not look
> good because it overlaps the attribute.
>
> In this case, I think it is better to keep things simple and remove the
> web config param and let the pool to be enabled only through the attribute
> or the entry in faces-config-extension. I'll do that.
>
> regards,
>
> Leonardo Uribe
>
>
>
> 2013/12/9 Thomas Andraschko <an...@gmail.com>
>
> Hi Leo,
>
> sounds fine! thanks :)
>
>
> 2013/12/9 Leonardo Uribe <lu...@gmail.com>
>
> Hi
>
> I think we could add it as a parameter for f:view tag, for example call it
> oamEnableViewPool. The patch proposed uses already an attribute for disable
> the pool in some cases, but after doing some experiments (MYFACES-3831) I
> have found we need to change some parts of the algorithm. Specifically I
> have found that it is not really necessary the check to disable the pool
> when VariableMapper  is used because with the code we have in place there
> is no way an EL expression should not be the same each time the view is
> built.
>
> A phaselistener is not necessary. I think the best place to set the param
> manually is ViewHandler.createView(...).
>
> regards,
>
> Leonardo Uribe
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Dora Rajappan <do...@yahoo.com>]

 
Thanks for explaining viewpool and viewstate. I will go through the code later and understand.
I was wondering what happens when state saving method param is not set. I got your point it that the state saving algorithm is performed and when its not mentioned whether it state saving method is client/server its assumed to save views in session and that might not have changed with view pool else it can affect maximum sequential views in session. I  have to go through the code to follow that. 
 
Regards,
Dora Rajappan.



On Saturday, December 14, 2013 3:53 AM, Leonardo Uribe <lu...@gmail.com> wrote:
  
Hi

"... When views are not transient and view pool enabled with no state saving or serialisation enabled ..." 


I don't get anything about what you mean. But I understand that the topic of state management is really, really complex, and has been a misunderstood problem for years in the world of web application development. So I'm going to clarify your confusion:

1. If the view is "transient" then the view is considered "stateless". No state saving is performed over stateless views, but since the view pool reuses state saving algorithm the view is not reused by the view pool algorithm.
2. If the view is not "transient", state saving algorithm is performed.
3. You CAN'T disable state saving. There is no web config parameter to do that, not to mention that a param to do that would be completely pointless, because the whole point of JSF is solve with the state problem to make applications in the web easier. 

4. StateManagementStrategy deals with the problem of how the vdl calculates the state, but it is not responsible of store the state. 
5. ResponseStateManger deals with two problems.

- Restore and save the state somewhere. In myfaces we included some classes for that: org.apache.myfaces.application.StateCacheFactory, org.apache.myfaces.application.StateCache. There are two basic implementations: ServerSideStateCacheImpl and ClientSideStateCacheImpl, but it can be more and it has been proposed to include a mixed mode. There is still work and some discussions to do in that part but they are not prioritary for now, but in the past it has been a controversial matter. The solution we have right now works just fine.

- Modify the response to include the necessary information to save and restore the state. This is done usually writing the javax.faces.ViewState and the javax.faces.ClientWindow.
6. StateManagementStrategy is affected by the view pool because in the calculation step we store or retrieve a view from the pool, but ResponseStateManger is not affected by the pool. Take a look at the code first.

regards,

Leonardo Uribe






2013/12/13 Dora Rajappan <do...@yahoo.com>

 
>Hi Leonardo,
> 
> Thanks for explaining that the statemanagementstrategy is unaffected by the view pooling. 
> When views are not transient and view pool enabled with no state saving or serialisation enabled, the view pool processing remain the same and the state is saved in session. 
>  
>Regards
>Dora Rajappan.
>
>
>
>On Friday, December 13, 2013 8:17 PM, Leonardo Uribe <lu...@gmail.com> wrote:
>  
>Hi
>
>
>
>2013/12/13 Dora Rajappan <do...@yahoo.com>
>
>Not bad +1 for view pool. 
>> 
>>When VIEW_POOL_ENABLED the param  org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is not considered and not required to set. 
>>org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is valid for state saving client/server. 
>
>
>View Pooling is all about "efficient memory management". The state saving algorithm is another different thing, and the view pool does not affect the way how state saving restoring works. I unfortunately have to say that your comment does not have sense. This feature is something new, ouside JSF 2.2 spec but proposed to be included in MyFaces 2.2. What we are doing here and we have done for more than 1 year is discuss and justify the addition of this feature.
>
>
>regards,
>
>Leonardo Uribe
>
>
>
>
>
>>
>>Regards,
>>Dora Rajappan.
>>
>>
>>
>>On Friday, December 13, 2013 2:21 PM, Thomas Andraschko <an...@gmail.com> wrote:
>>  
>>Cool leo! Thanks for your effort :)
>>
>>
>>
>>
>>
>>2013/12/13 Leonardo Uribe <lu...@gmail.com>
>>
>>Hi
>>>
>>>Finally the code for View Pooling has been comitted. After some performance 
>>>tests with the know demo application, it has been confirmed the following 
>>>improvements: 
>>>
>>>- A reduction of 25% of the transient memory used, which means a lot less 
>>>memory is used and it is used at a slower pace. It also means less GC calls
>>>and a better CPU usage.
>>>- An improvement of 9% over throughput for non ajax requests. 
>>>- An improvement from 9% to 30% or even more for ajax request, according to
>>>the tree size.
>>>
>>>These improvements are very good and justify the use of the view pool. But
>>>in order to be transparent and open with the community we have not explained
>>>the details behind how the view pool really works. So, I created a blog 
>>>about this topic that I hope to move it into MyFaces documentation once
>>>a release of 2.2.0 is out (we have some pending work to do in the 
>>>documentation area, so I hope to do everything in one step).
>>>
>>>http://lu4242.blogspot.com/2013/12/view-pooling-in-jsf-22-using-apache.html
>>>
>>>The blog summarize all information about this topic, its origins,
>>>the reasons behind them and the solution proposed, so we can discuss it later
>>>if there is any doubt or critic about it. It is a long story but this is 
>>>something we need to document properly.
>>>
>>>regards,
>>>
>>>Leonardo Uribe
>>>
>>>
>>>
>>>
>>>2013/12/9 Leonardo Uribe <lu...@gmail.com>
>>>
>>>Hi
>>>>
>>>>It seems we have an inconsistency between what was proposed to enable the view pool and the inclusion of the new parameter.
>>>>
>>>>At start we have this:
>>>>
>>>>
>>>>org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in the app, by default false)
>>>>
>>>>
>>>>
>>>>But if we use an attribute in f:view like "oamEnableViewPool", aiming to select the views that will use the pool, the previous param does not look good because it overlaps the attribute.
>>>>
>>>>
>>>>In this case, I think it is better to keep things simple and remove the web config param and let the pool to be enabled only through the attribute or the entry in faces-config-extension. I'll do that.
>>>> 
>>>>
>>>>regards,
>>>>
>>>>Leonardo Uribe
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>2013/12/9 Thomas Andraschko <an...@gmail.com>
>>>>
>>>>Hi Leo,
>>>>>
>>>>>sounds fine! thanks :)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>2013/12/9 Leonardo Uribe <lu...@gmail.com>
>>>>>
>>>>>Hi
>>>>>>
>>>>>>
>>>>>>I think we could add it as a parameter for f:view tag, for example call it oamEnableViewPool. The patch proposed uses already an attribute for disable the pool in some cases, but after doing some experiments (MYFACES-3831) I have found we need to change some parts of the algorithm. Specifically I have found that it is not really necessary the check to disable the pool when VariableMapper  is used because with the code we have in place there is no way an EL expression should not be the same each time the view is built.
>>>>>>
>>>>>>
>>>>>>A phaselistener is not necessary. I think the best place to set the param manually is ViewHandler.createView(...).
>>>>>>
>>>>>>
>>>>>>
>>>>>>regards,
>>>>>>
>>>>>>
>>>>>>Leonardo Uribe
>>>>>> 
>>>>> 
>>>> 
>>> 
>>
>>
>>    
>
> 
>
>    

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Leonardo Uribe <lu...@gmail.com>]

Hi

"... When views are not transient and view pool enabled with no state
saving or serialisation enabled ..."


I don't get anything about what you mean. But I understand that the topic
of state management is really, really complex, and has been a misunderstood
problem for years in the world of web application development. So I'm going
to clarify your confusion:

1. If the view is "transient" then the view is considered "stateless". No
state saving is performed over stateless views, but since the view pool
reuses state saving algorithm the view is not reused by the view pool
algorithm.
2. If the view is not "transient", state saving algorithm is performed.
3. You CAN'T disable state saving. There is no web config parameter to do
that, not to mention that a param to do that would be completely pointless,
because the whole point of JSF is solve with the state problem to make
applications in the web easier.
4. StateManagementStrategy deals with the problem of how the vdl calculates
the state, but it is not responsible of store the state.
5. ResponseStateManger deals with two problems.
- Restore and save the state somewhere. In myfaces we included some classes
for that: org.apache.myfaces.application.StateCacheFactory,
org.apache.myfaces.application.StateCache. There are two basic
implementations: ServerSideStateCacheImpl and ClientSideStateCacheImpl, but
it can be more and it has been proposed to include a mixed mode. There is
still work and some discussions to do in that part but they are not
prioritary for now, but in the past it has been a controversial matter. The
solution we have right now works just fine.
- Modify the response to include the necessary information to save and
restore the state. This is done usually writing the javax.faces.ViewState
and the javax.faces.ClientWindow.
6. StateManagementStrategy is affected by the view pool because in the
calculation step we store or retrieve a view from the pool, but
ResponseStateManger
is not affected by the pool. Take a look at the code first.

regards,

Leonardo Uribe




2013/12/13 Dora Rajappan <do...@yahoo.com>

>
> Hi Leonardo,
>
>  Thanks for explaining that the statemanagementstrategy is unaffected by
> the view pooling.
>  When views are not transient and view pool enabled with no state saving
> or serialisation enabled, the view pool processing remain the same and the
> state is saved in session.
>
> Regards
> Dora Rajappan.
>
>
>   On Friday, December 13, 2013 8:17 PM, Leonardo Uribe <lu...@gmail.com>
> wrote:
>  Hi
>
> 2013/12/13 Dora Rajappan <do...@yahoo.com>
>
> Not bad +1 for view pool.
>
> When VIEW_POOL_ENABLED the param
> org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION<http://myfaces.apache.org/core21/myfaces-impl/webconfig.html#org_apache_myfaces_NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION> is
> not considered and not required to set.
> org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION<http://myfaces.apache.org/core21/myfaces-impl/webconfig.html#org_apache_myfaces_NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION> is
> valid for state saving client/server.
>
>
> View Pooling is all about "efficient memory management". The state saving
> algorithm is another different thing, and the view pool does not affect the
> way how state saving restoring works. I unfortunately have to say that your
> comment does not have sense. This feature is something new, ouside JSF 2.2
> spec but proposed to be included in MyFaces 2.2. What we are doing here and
> we have done for more than 1 year is discuss and justify the addition of
> this feature.
>
> regards,
>
> Leonardo Uribe
>
>
>
>
> Regards,
> Dora Rajappan.
>
>
>   On Friday, December 13, 2013 2:21 PM, Thomas Andraschko <
> andraschko.thomas@gmail.com> wrote:
>  Cool leo! Thanks for your effort :)
>
>
>
> 2013/12/13 Leonardo Uribe <lu...@gmail.com>
>
> Hi
>
> Finally the code for View Pooling has been comitted. After some
> performance
> tests with the know demo application, it has been confirmed the following
> improvements:
>
> - A reduction of 25% of the transient memory used, which means a lot less
> memory is used and it is used at a slower pace. It also means less GC calls
> and a better CPU usage.
> - An improvement of 9% over throughput for non ajax requests.
> - An improvement from 9% to 30% or even more for ajax request, according to
> the tree size.
>
> These improvements are very good and justify the use of the view pool. But
> in order to be transparent and open with the community we have not
> explained
> the details behind how the view pool really works. So, I created a blog
> about this topic that I hope to move it into MyFaces documentation once
> a release of 2.2.0 is out (we have some pending work to do in the
> documentation area, so I hope to do everything in one step).
>
> http://lu4242.blogspot.com/2013/12/view-pooling-in-jsf-22-using-apache.html
>
> The blog summarize all information about this topic, its origins,
> the reasons behind them and the solution proposed, so we can discuss it
> later
> if there is any doubt or critic about it. It is a long story but this is
> something we need to document properly.
>
> regards,
>
> Leonardo Uribe
>
>
> 2013/12/9 Leonardo Uribe <lu...@gmail.com>
>
> Hi
>
> It seems we have an inconsistency between what was proposed to enable the
> view pool and the inclusion of the new parameter.
>
> At start we have this:
>
> org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in
> the app, by default false)
>
> But if we use an attribute in f:view like "oamEnableViewPool", aiming to
> select the views that will use the pool, the previous param does not look
> good because it overlaps the attribute.
>
> In this case, I think it is better to keep things simple and remove the
> web config param and let the pool to be enabled only through the attribute
> or the entry in faces-config-extension. I'll do that.
>
> regards,
>
> Leonardo Uribe
>
>
>
> 2013/12/9 Thomas Andraschko <an...@gmail.com>
>
> Hi Leo,
>
> sounds fine! thanks :)
>
>
> 2013/12/9 Leonardo Uribe <lu...@gmail.com>
>
> Hi
>
> I think we could add it as a parameter for f:view tag, for example call it
> oamEnableViewPool. The patch proposed uses already an attribute for disable
> the pool in some cases, but after doing some experiments (MYFACES-3831) I
> have found we need to change some parts of the algorithm. Specifically I
> have found that it is not really necessary the check to disable the pool
> when VariableMapper  is used because with the code we have in place there
> is no way an EL expression should not be the same each time the view is
> built.
>
> A phaselistener is not necessary. I think the best place to set the param
> manually is ViewHandler.createView(...).
>
> regards,
>
> Leonardo Uribe
>
>
>
>
>
>
>
>
>
>
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Dora Rajappan <do...@yahoo.com>]

 
Hi Leonardo,
 
 Thanks for explaining that the statemanagementstrategy is unaffected by the view pooling.
 When views are not transient and view pool enabled with no state saving or serialisation enabled, the view pool processing remain the same and the state is saved in session. 
 
Regards
Dora Rajappan.



On Friday, December 13, 2013 8:17 PM, Leonardo Uribe <lu...@gmail.com> wrote:
  
Hi



2013/12/13 Dora Rajappan <do...@yahoo.com>

Not bad +1 for view pool. 
> 
>When VIEW_POOL_ENABLED the param  org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is not considered and not required to set. 
>org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is valid for state saving client/server. 

View Pooling is all about "efficient memory management". The state saving algorithm is another different thing, and the view pool does not affect the way how state saving restoring works. I unfortunately have to say that your comment does not have sense. This feature is something new, ouside JSF 2.2 spec but proposed to be included in MyFaces 2.2. What we are doing here and we have done for more than 1 year is discuss and justify the addition of this feature.


regards,

Leonardo Uribe




>
>Regards,
>Dora Rajappan.
>
>
>
>On Friday, December 13, 2013 2:21 PM, Thomas Andraschko <an...@gmail.com> wrote:
>  
>Cool leo! Thanks for your effort :)
>
>
>
>
>
>2013/12/13 Leonardo Uribe <lu...@gmail.com>
>
>Hi
>>
>>Finally the code for View Pooling has been comitted. After some performance 
>>tests with the know demo application, it has been confirmed the following 
>>improvements: 
>>
>>- A reduction of 25% of the transient memory used, which means a lot less 
>>memory is used and it is used at a slower pace. It also means less GC calls
>>and a better CPU usage.
>>- An improvement of 9% over throughput for non ajax requests. 
>>- An improvement from 9% to 30% or even more for ajax request, according to
>>the tree size.
>>
>>These improvements are very good and justify the use of the view pool. But
>>in order to be transparent and open with the community we have not explained
>>the details behind how the view pool really works. So, I created a blog 
>>about this topic that I hope to move it into MyFaces documentation once
>>a release of 2.2.0 is out (we have some pending work to do in the 
>>documentation area, so I hope to do everything in one step).
>>
>>http://lu4242.blogspot.com/2013/12/view-pooling-in-jsf-22-using-apache.html
>>
>>The blog summarize all information about this topic, its origins,
>>the reasons behind them and the solution proposed, so we can discuss it later
>>if there is any doubt or critic about it. It is a long story but this is 
>>something we need to document properly.
>>
>>regards,
>>
>>Leonardo Uribe
>>
>>
>>
>>
>>2013/12/9 Leonardo Uribe <lu...@gmail.com>
>>
>>Hi
>>>
>>>It seems we have an inconsistency between what was proposed to enable the view pool and the inclusion of the new parameter.
>>>
>>>At start we have this:
>>>
>>>
>>>org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in the app, by default false)
>>>
>>>
>>>
>>>But if we use an attribute in f:view like "oamEnableViewPool", aiming to select the views that will use the pool, the previous param does not look good because it overlaps the attribute.
>>>
>>>
>>>In this case, I think it is better to keep things simple and remove the web config param and let the pool to be enabled only through the attribute or the entry in faces-config-extension. I'll do that.
>>> 
>>>
>>>regards,
>>>
>>>Leonardo Uribe
>>>
>>>
>>>
>>>
>>>
>>>2013/12/9 Thomas Andraschko <an...@gmail.com>
>>>
>>>Hi Leo,
>>>>
>>>>sounds fine! thanks :)
>>>>
>>>>
>>>>
>>>>
>>>>2013/12/9 Leonardo Uribe <lu...@gmail.com>
>>>>
>>>>Hi
>>>>>
>>>>>
>>>>>I think we could add it as a parameter for f:view tag, for example call it oamEnableViewPool. The patch proposed uses already an attribute for disable the pool in some cases, but after doing some experiments (MYFACES-3831) I have found we need to change some parts of the algorithm. Specifically I have found that it is not really necessary the check to disable the pool when VariableMapper  is used because with the code we have in place there is no way an EL expression should not be the same each time the view is built.
>>>>>
>>>>>
>>>>>A phaselistener is not necessary. I think the best place to set the param manually is ViewHandler.createView(...).
>>>>>
>>>>>
>>>>>
>>>>>regards,
>>>>>
>>>>>
>>>>>Leonardo Uribe
>>>>> 
>>>> 
>>> 
>> 
>
>
>    

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Leonardo Uribe <lu...@gmail.com>]

Hi

2013/12/13 Dora Rajappan <do...@yahoo.com>

> Not bad +1 for view pool.
>
> When VIEW_POOL_ENABLED the param
> org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION<http://myfaces.apache.org/core21/myfaces-impl/webconfig.html#org_apache_myfaces_NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION> is
> not considered and not required to set.
> org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION<http://myfaces.apache.org/core21/myfaces-impl/webconfig.html#org_apache_myfaces_NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION> is
> valid for state saving client/server.
>

View Pooling is all about "efficient memory management". The state saving
algorithm is another different thing, and the view pool does not affect the
way how state saving restoring works. I unfortunately have to say that your
comment does not have sense. This feature is something new, ouside JSF 2.2
spec but proposed to be included in MyFaces 2.2. What we are doing here and
we have done for more than 1 year is discuss and justify the addition of
this feature.

regards,

Leonardo Uribe


>
> Regards,
> Dora Rajappan.
>
>
>   On Friday, December 13, 2013 2:21 PM, Thomas Andraschko <
> andraschko.thomas@gmail.com> wrote:
>  Cool leo! Thanks for your effort :)
>
>
>
> 2013/12/13 Leonardo Uribe <lu...@gmail.com>
>
> Hi
>
> Finally the code for View Pooling has been comitted. After some
> performance
> tests with the know demo application, it has been confirmed the following
> improvements:
>
> - A reduction of 25% of the transient memory used, which means a lot less
> memory is used and it is used at a slower pace. It also means less GC calls
> and a better CPU usage.
> - An improvement of 9% over throughput for non ajax requests.
> - An improvement from 9% to 30% or even more for ajax request, according to
> the tree size.
>
> These improvements are very good and justify the use of the view pool. But
> in order to be transparent and open with the community we have not
> explained
> the details behind how the view pool really works. So, I created a blog
> about this topic that I hope to move it into MyFaces documentation once
> a release of 2.2.0 is out (we have some pending work to do in the
> documentation area, so I hope to do everything in one step).
>
> http://lu4242.blogspot.com/2013/12/view-pooling-in-jsf-22-using-apache.html
>
> The blog summarize all information about this topic, its origins,
> the reasons behind them and the solution proposed, so we can discuss it
> later
> if there is any doubt or critic about it. It is a long story but this is
> something we need to document properly.
>
> regards,
>
> Leonardo Uribe
>
>
> 2013/12/9 Leonardo Uribe <lu...@gmail.com>
>
> Hi
>
> It seems we have an inconsistency between what was proposed to enable the
> view pool and the inclusion of the new parameter.
>
> At start we have this:
>
> org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in
> the app, by default false)
>
> But if we use an attribute in f:view like "oamEnableViewPool", aiming to
> select the views that will use the pool, the previous param does not look
> good because it overlaps the attribute.
>
> In this case, I think it is better to keep things simple and remove the
> web config param and let the pool to be enabled only through the attribute
> or the entry in faces-config-extension. I'll do that.
>
> regards,
>
> Leonardo Uribe
>
>
>
> 2013/12/9 Thomas Andraschko <an...@gmail.com>
>
> Hi Leo,
>
> sounds fine! thanks :)
>
>
> 2013/12/9 Leonardo Uribe <lu...@gmail.com>
>
> Hi
>
> I think we could add it as a parameter for f:view tag, for example call it
> oamEnableViewPool. The patch proposed uses already an attribute for disable
> the pool in some cases, but after doing some experiments (MYFACES-3831) I
> have found we need to change some parts of the algorithm. Specifically I
> have found that it is not really necessary the check to disable the pool
> when VariableMapper  is used because with the code we have in place there
> is no way an EL expression should not be the same each time the view is
> built.
>
> A phaselistener is not necessary. I think the best place to set the param
> manually is ViewHandler.createView(...).
>
> regards,
>
> Leonardo Uribe
>
>
>
>
>
>
>
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Dora Rajappan <do...@yahoo.com>]

Not bad +1 for view pool. 
 
When VIEW_POOL_ENABLED the param  org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is not considered and not required to set.
org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is valid for state saving client/server.
 
Regards,
Dora Rajappan.



On Friday, December 13, 2013 2:21 PM, Thomas Andraschko <an...@gmail.com> wrote:
  
Cool leo! Thanks for your effort :)





2013/12/13 Leonardo Uribe <lu...@gmail.com>

Hi
>
>Finally the code for View Pooling has been comitted. After some performance 
>tests with the know demo application, it has been confirmed the following 
>improvements: 
>
>- A reduction of 25% of the transient memory used, which means a lot less 
>memory is used and it is used at a slower pace. It also means less GC calls
>and a better CPU usage.
>- An improvement of 9% over throughput for non ajax requests. 
>- An improvement from 9% to 30% or even more for ajax request, according to
>the tree size.
>
>These improvements are very good and justify the use of the view pool. But
>in order to be transparent and open with the community we have not explained
>the details behind how the view pool really works. So, I created a blog 
>about this topic that I hope to move it into MyFaces documentation once
>a release of 2.2.0 is out (we have some pending work to do in the 
>documentation area, so I hope to do everything in one step).
>
>http://lu4242.blogspot.com/2013/12/view-pooling-in-jsf-22-using-apache.html
>
>The blog summarize all information about this topic, its origins,
>the reasons behind them and the solution proposed, so we can discuss it later
>if there is any doubt or critic about it. It is a long story but this is 
>something we need to document properly.
>
>regards,
>
>Leonardo Uribe
>
>
>
>
>2013/12/9 Leonardo Uribe <lu...@gmail.com>
>
>Hi
>>
>>It seems we have an inconsistency between what was proposed to enable the view pool and the inclusion of the new parameter.
>>
>>At start we have this:
>>
>>
>>org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in the app, by default false)
>>
>>
>>
>>But if we use an attribute in f:view like "oamEnableViewPool", aiming to select the views that will use the pool, the previous param does not look good because it overlaps the attribute.
>>
>>
>>In this case, I think it is better to keep things simple and remove the web config param and let the pool to be enabled only through the attribute or the entry in faces-config-extension. I'll do that.
>> 
>>
>>regards,
>>
>>Leonardo Uribe
>>
>>
>>
>>
>>
>>2013/12/9 Thomas Andraschko <an...@gmail.com>
>>
>>Hi Leo,
>>>
>>>sounds fine! thanks :)
>>>
>>>
>>>
>>>
>>>2013/12/9 Leonardo Uribe <lu...@gmail.com>
>>>
>>>Hi
>>>>
>>>>
>>>>I think we could add it as a parameter for f:view tag, for example call it oamEnableViewPool. The patch proposed uses already an attribute for disable the pool in some cases, but after doing some experiments (MYFACES-3831) I have found we need to change some parts of the algorithm. Specifically I have found that it is not really necessary the check to disable the pool when VariableMapper  is used because with the code we have in place there is no way an EL expression should not be the same each time the view is built.
>>>>
>>>>
>>>>A phaselistener is not necessary. I think the best place to set the param manually is ViewHandler.createView(...).
>>>>
>>>>
>>>>
>>>>regards,
>>>>
>>>>
>>>>Leonardo Uribe
>>>> 
>>> 
>> 
> 

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Thomas Andraschko <an...@gmail.com>]

Cool leo! Thanks for your effort :)



2013/12/13 Leonardo Uribe <lu...@gmail.com>

> Hi
>
> Finally the code for View Pooling has been comitted. After some
> performance
> tests with the know demo application, it has been confirmed the following
> improvements:
>
> - A reduction of 25% of the transient memory used, which means a lot less
> memory is used and it is used at a slower pace. It also means less GC calls
> and a better CPU usage.
> - An improvement of 9% over throughput for non ajax requests.
> - An improvement from 9% to 30% or even more for ajax request, according to
> the tree size.
>
> These improvements are very good and justify the use of the view pool. But
> in order to be transparent and open with the community we have not
> explained
> the details behind how the view pool really works. So, I created a blog
> about this topic that I hope to move it into MyFaces documentation once
> a release of 2.2.0 is out (we have some pending work to do in the
> documentation area, so I hope to do everything in one step).
>
> http://lu4242.blogspot.com/2013/12/view-pooling-in-jsf-22-using-apache.html
>
> The blog summarize all information about this topic, its origins,
> the reasons behind them and the solution proposed, so we can discuss it
> later
> if there is any doubt or critic about it. It is a long story but this is
> something we need to document properly.
>
> regards,
>
> Leonardo Uribe
>
>
> 2013/12/9 Leonardo Uribe <lu...@gmail.com>
>
>> Hi
>>
>> It seems we have an inconsistency between what was proposed to enable the
>> view pool and the inclusion of the new parameter.
>>
>> At start we have this:
>>
>> org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in
>> the app, by default false)
>>
>> But if we use an attribute in f:view like "oamEnableViewPool", aiming to
>> select the views that will use the pool, the previous param does not look
>> good because it overlaps the attribute.
>>
>> In this case, I think it is better to keep things simple and remove the
>> web config param and let the pool to be enabled only through the attribute
>> or the entry in faces-config-extension. I'll do that.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>>
>> 2013/12/9 Thomas Andraschko <an...@gmail.com>
>>
>>> Hi Leo,
>>>
>>> sounds fine! thanks :)
>>>
>>>
>>> 2013/12/9 Leonardo Uribe <lu...@gmail.com>
>>>
>>>> Hi
>>>>
>>>> I think we could add it as a parameter for f:view tag, for example call
>>>> it oamEnableViewPool. The patch proposed uses already an attribute for
>>>> disable the pool in some cases, but after doing some experiments
>>>> (MYFACES-3831) I have found we need to change some parts of the algorithm.
>>>> Specifically I have found that it is not really necessary the check to
>>>> disable the pool when VariableMapper  is used because with the code we have
>>>> in place there is no way an EL expression should not be the same each time
>>>> the view is built.
>>>>
>>>> A phaselistener is not necessary. I think the best place to set the
>>>> param manually is ViewHandler.createView(...).
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>
>>>
>>
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Leonardo Uribe <lu...@gmail.com>]

Hi

Finally the code for View Pooling has been comitted. After some performance
tests with the know demo application, it has been confirmed the following
improvements:

- A reduction of 25% of the transient memory used, which means a lot less
memory is used and it is used at a slower pace. It also means less GC calls
and a better CPU usage.
- An improvement of 9% over throughput for non ajax requests.
- An improvement from 9% to 30% or even more for ajax request, according to
the tree size.

These improvements are very good and justify the use of the view pool. But
in order to be transparent and open with the community we have not explained
the details behind how the view pool really works. So, I created a blog
about this topic that I hope to move it into MyFaces documentation once
a release of 2.2.0 is out (we have some pending work to do in the
documentation area, so I hope to do everything in one step).

http://lu4242.blogspot.com/2013/12/view-pooling-in-jsf-22-using-apache.html

The blog summarize all information about this topic, its origins,
the reasons behind them and the solution proposed, so we can discuss it
later
if there is any doubt or critic about it. It is a long story but this is
something we need to document properly.

regards,

Leonardo Uribe


2013/12/9 Leonardo Uribe <lu...@gmail.com>

> Hi
>
> It seems we have an inconsistency between what was proposed to enable the
> view pool and the inclusion of the new parameter.
>
> At start we have this:
>
> org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in
> the app, by default false)
>
> But if we use an attribute in f:view like "oamEnableViewPool", aiming to
> select the views that will use the pool, the previous param does not look
> good because it overlaps the attribute.
>
> In this case, I think it is better to keep things simple and remove the
> web config param and let the pool to be enabled only through the attribute
> or the entry in faces-config-extension. I'll do that.
>
> regards,
>
> Leonardo Uribe
>
>
>
> 2013/12/9 Thomas Andraschko <an...@gmail.com>
>
>> Hi Leo,
>>
>> sounds fine! thanks :)
>>
>>
>> 2013/12/9 Leonardo Uribe <lu...@gmail.com>
>>
>>> Hi
>>>
>>> I think we could add it as a parameter for f:view tag, for example call
>>> it oamEnableViewPool. The patch proposed uses already an attribute for
>>> disable the pool in some cases, but after doing some experiments
>>> (MYFACES-3831) I have found we need to change some parts of the algorithm.
>>> Specifically I have found that it is not really necessary the check to
>>> disable the pool when VariableMapper  is used because with the code we have
>>> in place there is no way an EL expression should not be the same each time
>>> the view is built.
>>>
>>> A phaselistener is not necessary. I think the best place to set the
>>> param manually is ViewHandler.createView(...).
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>
>>
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Leonardo Uribe <lu...@gmail.com>]

Hi

It seems we have an inconsistency between what was proposed to enable the
view pool and the inclusion of the new parameter.

At start we have this:

org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in the
app, by default false)

But if we use an attribute in f:view like "oamEnableViewPool", aiming to
select the views that will use the pool, the previous param does not look
good because it overlaps the attribute.

In this case, I think it is better to keep things simple and remove the web
config param and let the pool to be enabled only through the attribute or
the entry in faces-config-extension. I'll do that.

regards,

Leonardo Uribe



2013/12/9 Thomas Andraschko <an...@gmail.com>

> Hi Leo,
>
> sounds fine! thanks :)
>
>
> 2013/12/9 Leonardo Uribe <lu...@gmail.com>
>
>> Hi
>>
>> I think we could add it as a parameter for f:view tag, for example call
>> it oamEnableViewPool. The patch proposed uses already an attribute for
>> disable the pool in some cases, but after doing some experiments
>> (MYFACES-3831) I have found we need to change some parts of the algorithm.
>> Specifically I have found that it is not really necessary the check to
>> disable the pool when VariableMapper  is used because with the code we have
>> in place there is no way an EL expression should not be the same each time
>> the view is built.
>>
>> A phaselistener is not necessary. I think the best place to set the param
>> manually is ViewHandler.createView(...).
>>
>> regards,
>>
>> Leonardo Uribe
>>
>
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Thomas Andraschko <an...@gmail.com>]

Hi Leo,

sounds fine! thanks :)


2013/12/9 Leonardo Uribe <lu...@gmail.com>

> Hi
>
> I think we could add it as a parameter for f:view tag, for example call it
> oamEnableViewPool. The patch proposed uses already an attribute for disable
> the pool in some cases, but after doing some experiments (MYFACES-3831) I
> have found we need to change some parts of the algorithm. Specifically I
> have found that it is not really necessary the check to disable the pool
> when VariableMapper  is used because with the code we have in place there
> is no way an EL expression should not be the same each time the view is
> built.
>
> A phaselistener is not necessary. I think the best place to set the param
> manually is ViewHandler.createView(...).
>
> regards,
>
> Leonardo Uribe
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Leonardo Uribe <lu...@gmail.com>]

Hi

I think we could add it as a parameter for f:view tag, for example call it
oamEnableViewPool. The patch proposed uses already an attribute for disable
the pool in some cases, but after doing some experiments (MYFACES-3831) I
have found we need to change some parts of the algorithm. Specifically I
have found that it is not really necessary the check to disable the pool
when VariableMapper  is used because with the code we have in place there
is no way an EL expression should not be the same each time the view is
built.

A phaselistener is not necessary. I think the best place to set the param
manually is ViewHandler.createView(...).

regards,

Leonardo Uribe

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Thomas Andraschko <an...@gmail.com>]

Hi Leo,

a attribute for the viewroot sound greats. +1.
How would you set this attribute then?
Setting the attribute should only be required one time - so maybe a
PhaseListener isn't the best place.

Regards,
Thomas



2013/12/7 Leonardo Uribe <lu...@gmail.com>

> Hi Thomas
>
> What I can do is use an attribute to mark the view as poolable or not
> poolable.
>
> The annotation code must be done outside core.
>
> regards,
>
> Leonardo
>
>
>
> 2013/12/7 Thomas Andraschko <an...@gmail.com>
>
>> Leo, one question:
>> Is it possible to mark a view as "poolable" via code?
>> We configure all our views via typesafe view config from CODI/DS
>>
>>
>>
>> 2013/12/4 Thomas Andraschko <an...@gmail.com>
>>
>>> Looks fine for me!
>>>
>>>
>>> 2013/12/3 Leonardo Uribe <lu...@gmail.com>
>>>
>>>> Hi
>>>>
>>>> I have been thinking about how to define the configuration for the view
>>>> pool. The idea is add the following new web config parameters:
>>>>
>>>> org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in
>>>> the app, by default false)
>>>> org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE (the number of views stored
>>>> in the pool per key)
>>>> org.apache.myfaces.VIEW_POOL_MAX_DYNAMIC_PARTIAL_LIMIT (the number of
>>>> dyn views that can be used as partial)
>>>> org.apache.myfaces.VIEW_POOL_ENTRY_MODE (weak, soft)
>>>> org.apache.myfaces.VIEW_POOL_DEFERRED_NAVIGATION (reuse views that are
>>>> navigated using default algorithm (increase reusal but it uses a hack that
>>>> does not follow jsf spec) )
>>>>
>>>> And include this possible extension in faces-config.xml:
>>>>
>>>>     <faces-config-extension>
>>>>         <view-pool-mapping>
>>>>             <url-pattern>/*</url-pattern>
>>>>             <parameter>
>>>>                 <name>org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE</name>
>>>>                 <value>5</value>
>>>>             </parameter>
>>>>         </view-pool-mapping>
>>>>     </faces-config-extension>
>>>>
>>>> The idea is allow users to enable the view pool only for a part of the
>>>> application using <url-pattern> and override some specific view pool
>>>> parameters. The idea is there are parts of the application that are used
>>>> quite intensively and others that are not frequently visited.
>>>>
>>>> Suggestions are welcome.
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>>
>>>>
>>>> 2013/11/25 Martin Kočí <ma...@gmail.com>
>>>>
>>>>> Hi,
>>>>>
>>>>> +1 for this feature in core 2.2.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Kocicak
>>>>>
>>>>>
>>>>>
>>>>> 2013/11/24 Thomas Andraschko <an...@gmail.com>
>>>>>
>>>>>> Perfect. Thanks for Info.
>>>>>>
>>>>>> So +1 from my side.
>>>>>>
>>>>>>
>>>>>> 2013/11/24 Leonardo Uribe <lu...@gmail.com>
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> 2013/11/24 Thomas Andraschko <an...@gmail.com>
>>>>>>>
>>>>>>>> Hi Leo,
>>>>>>>>
>>>>>>>>  By default all the code in UIComponentBase is already in place, so
>>>>>>>>> if all components extend from UIComponentBase everything will work just fine
>>>>>>>>
>>>>>>>>
>>>>>>>> cool, perfect!
>>>>>>>>
>>>>>>>> What about Behaviors or ActionListeners like:
>>>>>>>>
>>>>>>>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/component/collector/Collector.java
>>>>>>>>
>>>>>>>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java
>>>>>>>>
>>>>>>>> Will they work correctly?
>>>>>>>>
>>>>>>>
>>>>>>> Yes, because the related variables are stored into the state, so if
>>>>>>> they change, saveState(...) will return non null and in the worst case the
>>>>>>> component will be replaced with a new one.
>>>>>>>
>>>>>>> The ideal is the attached objects (Collector) implements
>>>>>>> PartialStateHolder instead StateHolder. The reason is the hack involves
>>>>>>> save the state when markInitialState(...) was called and when a hard reset
>>>>>>> is done, reuse that information and restore the state of the component or
>>>>>>> attached object like it was when the view was built by first time. But if
>>>>>>> that is not done, the algorithm just replace the component with a new one
>>>>>>> and problem solved.
>>>>>>>
>>>>>>> The tricky part are those variables that are not part of the state
>>>>>>> buy plays some role, because there is no way to know they are there. For
>>>>>>> example the dataModelMap in UIData, but the examples out there are very
>>>>>>> few.
>>>>>>>
>>>>>>>
>>>>>>>> All other components in PrimeFaces just use the StateHelper. So it
>>>>>>>> should be fine.
>>>>>>>>
>>>>>>>>
>>>>>>> If saveState(...) is overriden, there is a chance that some
>>>>>>> additional lines are required.
>>>>>>>
>>>>>>> Note we still have a lot of work to do, but the evidence we have
>>>>>>> suggest we should at least give another try and see what happens.
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Leonardo Uribe
>>>>>>>
>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Leonardo Uribe <lu...@gmail.com>]

Hi Thomas

What I can do is use an attribute to mark the view as poolable or not
poolable.

The annotation code must be done outside core.

regards,

Leonardo



2013/12/7 Thomas Andraschko <an...@gmail.com>

> Leo, one question:
> Is it possible to mark a view as "poolable" via code?
> We configure all our views via typesafe view config from CODI/DS
>
>
>
> 2013/12/4 Thomas Andraschko <an...@gmail.com>
>
>> Looks fine for me!
>>
>>
>> 2013/12/3 Leonardo Uribe <lu...@gmail.com>
>>
>>> Hi
>>>
>>> I have been thinking about how to define the configuration for the view
>>> pool. The idea is add the following new web config parameters:
>>>
>>> org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in
>>> the app, by default false)
>>> org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE (the number of views stored
>>> in the pool per key)
>>> org.apache.myfaces.VIEW_POOL_MAX_DYNAMIC_PARTIAL_LIMIT (the number of
>>> dyn views that can be used as partial)
>>> org.apache.myfaces.VIEW_POOL_ENTRY_MODE (weak, soft)
>>> org.apache.myfaces.VIEW_POOL_DEFERRED_NAVIGATION (reuse views that are
>>> navigated using default algorithm (increase reusal but it uses a hack that
>>> does not follow jsf spec) )
>>>
>>> And include this possible extension in faces-config.xml:
>>>
>>>     <faces-config-extension>
>>>         <view-pool-mapping>
>>>             <url-pattern>/*</url-pattern>
>>>             <parameter>
>>>                 <name>org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE</name>
>>>                 <value>5</value>
>>>             </parameter>
>>>         </view-pool-mapping>
>>>     </faces-config-extension>
>>>
>>> The idea is allow users to enable the view pool only for a part of the
>>> application using <url-pattern> and override some specific view pool
>>> parameters. The idea is there are parts of the application that are used
>>> quite intensively and others that are not frequently visited.
>>>
>>> Suggestions are welcome.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>
>>>
>>> 2013/11/25 Martin Kočí <ma...@gmail.com>
>>>
>>>> Hi,
>>>>
>>>> +1 for this feature in core 2.2.
>>>>
>>>> Regards,
>>>>
>>>> Kocicak
>>>>
>>>>
>>>>
>>>> 2013/11/24 Thomas Andraschko <an...@gmail.com>
>>>>
>>>>> Perfect. Thanks for Info.
>>>>>
>>>>> So +1 from my side.
>>>>>
>>>>>
>>>>> 2013/11/24 Leonardo Uribe <lu...@gmail.com>
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> 2013/11/24 Thomas Andraschko <an...@gmail.com>
>>>>>>
>>>>>>> Hi Leo,
>>>>>>>
>>>>>>>  By default all the code in UIComponentBase is already in place, so
>>>>>>>> if all components extend from UIComponentBase everything will work just fine
>>>>>>>
>>>>>>>
>>>>>>> cool, perfect!
>>>>>>>
>>>>>>> What about Behaviors or ActionListeners like:
>>>>>>>
>>>>>>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/component/collector/Collector.java
>>>>>>>
>>>>>>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java
>>>>>>>
>>>>>>> Will they work correctly?
>>>>>>>
>>>>>>
>>>>>> Yes, because the related variables are stored into the state, so if
>>>>>> they change, saveState(...) will return non null and in the worst case the
>>>>>> component will be replaced with a new one.
>>>>>>
>>>>>> The ideal is the attached objects (Collector) implements
>>>>>> PartialStateHolder instead StateHolder. The reason is the hack involves
>>>>>> save the state when markInitialState(...) was called and when a hard reset
>>>>>> is done, reuse that information and restore the state of the component or
>>>>>> attached object like it was when the view was built by first time. But if
>>>>>> that is not done, the algorithm just replace the component with a new one
>>>>>> and problem solved.
>>>>>>
>>>>>> The tricky part are those variables that are not part of the state
>>>>>> buy plays some role, because there is no way to know they are there. For
>>>>>> example the dataModelMap in UIData, but the examples out there are very
>>>>>> few.
>>>>>>
>>>>>>
>>>>>>> All other components in PrimeFaces just use the StateHelper. So it
>>>>>>> should be fine.
>>>>>>>
>>>>>>>
>>>>>> If saveState(...) is overriden, there is a chance that some
>>>>>> additional lines are required.
>>>>>>
>>>>>> Note we still have a lot of work to do, but the evidence we have
>>>>>> suggest we should at least give another try and see what happens.
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Leonardo Uribe
>>>>>>
>>>>>>
>>>>>>> Regards,
>>>>>>> Thomas
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Thomas Andraschko <an...@gmail.com>]

Leo, one question:
Is it possible to mark a view as "poolable" via code?
We configure all our views via typesafe view config from CODI/DS



2013/12/4 Thomas Andraschko <an...@gmail.com>

> Looks fine for me!
>
>
> 2013/12/3 Leonardo Uribe <lu...@gmail.com>
>
>> Hi
>>
>> I have been thinking about how to define the configuration for the view
>> pool. The idea is add the following new web config parameters:
>>
>> org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in
>> the app, by default false)
>> org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE (the number of views stored in
>> the pool per key)
>> org.apache.myfaces.VIEW_POOL_MAX_DYNAMIC_PARTIAL_LIMIT (the number of dyn
>> views that can be used as partial)
>> org.apache.myfaces.VIEW_POOL_ENTRY_MODE (weak, soft)
>> org.apache.myfaces.VIEW_POOL_DEFERRED_NAVIGATION (reuse views that are
>> navigated using default algorithm (increase reusal but it uses a hack that
>> does not follow jsf spec) )
>>
>> And include this possible extension in faces-config.xml:
>>
>>     <faces-config-extension>
>>         <view-pool-mapping>
>>             <url-pattern>/*</url-pattern>
>>             <parameter>
>>                 <name>org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE</name>
>>                 <value>5</value>
>>             </parameter>
>>         </view-pool-mapping>
>>     </faces-config-extension>
>>
>> The idea is allow users to enable the view pool only for a part of the
>> application using <url-pattern> and override some specific view pool
>> parameters. The idea is there are parts of the application that are used
>> quite intensively and others that are not frequently visited.
>>
>> Suggestions are welcome.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>>
>> 2013/11/25 Martin Kočí <ma...@gmail.com>
>>
>>> Hi,
>>>
>>> +1 for this feature in core 2.2.
>>>
>>> Regards,
>>>
>>> Kocicak
>>>
>>>
>>>
>>> 2013/11/24 Thomas Andraschko <an...@gmail.com>
>>>
>>>> Perfect. Thanks for Info.
>>>>
>>>> So +1 from my side.
>>>>
>>>>
>>>> 2013/11/24 Leonardo Uribe <lu...@gmail.com>
>>>>
>>>>> Hi
>>>>>
>>>>> 2013/11/24 Thomas Andraschko <an...@gmail.com>
>>>>>
>>>>>> Hi Leo,
>>>>>>
>>>>>>  By default all the code in UIComponentBase is already in place, so
>>>>>>> if all components extend from UIComponentBase everything will work just fine
>>>>>>
>>>>>>
>>>>>> cool, perfect!
>>>>>>
>>>>>> What about Behaviors or ActionListeners like:
>>>>>>
>>>>>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/component/collector/Collector.java
>>>>>>
>>>>>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java
>>>>>>
>>>>>> Will they work correctly?
>>>>>>
>>>>>
>>>>> Yes, because the related variables are stored into the state, so if
>>>>> they change, saveState(...) will return non null and in the worst case the
>>>>> component will be replaced with a new one.
>>>>>
>>>>> The ideal is the attached objects (Collector) implements
>>>>> PartialStateHolder instead StateHolder. The reason is the hack involves
>>>>> save the state when markInitialState(...) was called and when a hard reset
>>>>> is done, reuse that information and restore the state of the component or
>>>>> attached object like it was when the view was built by first time. But if
>>>>> that is not done, the algorithm just replace the component with a new one
>>>>> and problem solved.
>>>>>
>>>>> The tricky part are those variables that are not part of the state buy
>>>>> plays some role, because there is no way to know they are there. For
>>>>> example the dataModelMap in UIData, but the examples out there are very
>>>>> few.
>>>>>
>>>>>
>>>>>> All other components in PrimeFaces just use the StateHelper. So it
>>>>>> should be fine.
>>>>>>
>>>>>>
>>>>> If saveState(...) is overriden, there is a chance that some additional
>>>>> lines are required.
>>>>>
>>>>> Note we still have a lot of work to do, but the evidence we have
>>>>> suggest we should at least give another try and see what happens.
>>>>>
>>>>> regards,
>>>>>
>>>>> Leonardo Uribe
>>>>>
>>>>>
>>>>>> Regards,
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Thomas Andraschko <an...@gmail.com>]

Looks fine for me!


2013/12/3 Leonardo Uribe <lu...@gmail.com>

> Hi
>
> I have been thinking about how to define the configuration for the view
> pool. The idea is add the following new web config parameters:
>
> org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in
> the app, by default false)
> org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE (the number of views stored in
> the pool per key)
> org.apache.myfaces.VIEW_POOL_MAX_DYNAMIC_PARTIAL_LIMIT (the number of dyn
> views that can be used as partial)
> org.apache.myfaces.VIEW_POOL_ENTRY_MODE (weak, soft)
> org.apache.myfaces.VIEW_POOL_DEFERRED_NAVIGATION (reuse views that are
> navigated using default algorithm (increase reusal but it uses a hack that
> does not follow jsf spec) )
>
> And include this possible extension in faces-config.xml:
>
>     <faces-config-extension>
>         <view-pool-mapping>
>             <url-pattern>/*</url-pattern>
>             <parameter>
>                 <name>org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE</name>
>                 <value>5</value>
>             </parameter>
>         </view-pool-mapping>
>     </faces-config-extension>
>
> The idea is allow users to enable the view pool only for a part of the
> application using <url-pattern> and override some specific view pool
> parameters. The idea is there are parts of the application that are used
> quite intensively and others that are not frequently visited.
>
> Suggestions are welcome.
>
> regards,
>
> Leonardo Uribe
>
>
>
> 2013/11/25 Martin Kočí <ma...@gmail.com>
>
>> Hi,
>>
>> +1 for this feature in core 2.2.
>>
>> Regards,
>>
>> Kocicak
>>
>>
>>
>> 2013/11/24 Thomas Andraschko <an...@gmail.com>
>>
>>> Perfect. Thanks for Info.
>>>
>>> So +1 from my side.
>>>
>>>
>>> 2013/11/24 Leonardo Uribe <lu...@gmail.com>
>>>
>>>> Hi
>>>>
>>>> 2013/11/24 Thomas Andraschko <an...@gmail.com>
>>>>
>>>>> Hi Leo,
>>>>>
>>>>>  By default all the code in UIComponentBase is already in place, so if
>>>>>> all components extend from UIComponentBase everything will work just fine
>>>>>
>>>>>
>>>>> cool, perfect!
>>>>>
>>>>> What about Behaviors or ActionListeners like:
>>>>>
>>>>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/component/collector/Collector.java
>>>>>
>>>>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java
>>>>>
>>>>> Will they work correctly?
>>>>>
>>>>
>>>> Yes, because the related variables are stored into the state, so if
>>>> they change, saveState(...) will return non null and in the worst case the
>>>> component will be replaced with a new one.
>>>>
>>>> The ideal is the attached objects (Collector) implements
>>>> PartialStateHolder instead StateHolder. The reason is the hack involves
>>>> save the state when markInitialState(...) was called and when a hard reset
>>>> is done, reuse that information and restore the state of the component or
>>>> attached object like it was when the view was built by first time. But if
>>>> that is not done, the algorithm just replace the component with a new one
>>>> and problem solved.
>>>>
>>>> The tricky part are those variables that are not part of the state buy
>>>> plays some role, because there is no way to know they are there. For
>>>> example the dataModelMap in UIData, but the examples out there are very
>>>> few.
>>>>
>>>>
>>>>> All other components in PrimeFaces just use the StateHelper. So it
>>>>> should be fine.
>>>>>
>>>>>
>>>> If saveState(...) is overriden, there is a chance that some additional
>>>> lines are required.
>>>>
>>>> Note we still have a lot of work to do, but the evidence we have
>>>> suggest we should at least give another try and see what happens.
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>>
>>>>> Regards,
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Leonardo Uribe <lu...@gmail.com>]

Hi

I have been thinking about how to define the configuration for the view
pool. The idea is add the following new web config parameters:

org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in the
app, by default false)
org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE (the number of views stored in
the pool per key)
org.apache.myfaces.VIEW_POOL_MAX_DYNAMIC_PARTIAL_LIMIT (the number of dyn
views that can be used as partial)
org.apache.myfaces.VIEW_POOL_ENTRY_MODE (weak, soft)
org.apache.myfaces.VIEW_POOL_DEFERRED_NAVIGATION (reuse views that are
navigated using default algorithm (increase reusal but it uses a hack that
does not follow jsf spec) )

And include this possible extension in faces-config.xml:

    <faces-config-extension>
        <view-pool-mapping>
            <url-pattern>/*</url-pattern>
            <parameter>
                <name>org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE</name>
                <value>5</value>
            </parameter>
        </view-pool-mapping>
    </faces-config-extension>

The idea is allow users to enable the view pool only for a part of the
application using <url-pattern> and override some specific view pool
parameters. The idea is there are parts of the application that are used
quite intensively and others that are not frequently visited.

Suggestions are welcome.

regards,

Leonardo Uribe



2013/11/25 Martin Kočí <ma...@gmail.com>

> Hi,
>
> +1 for this feature in core 2.2.
>
> Regards,
>
> Kocicak
>
>
>
> 2013/11/24 Thomas Andraschko <an...@gmail.com>
>
>> Perfect. Thanks for Info.
>>
>> So +1 from my side.
>>
>>
>> 2013/11/24 Leonardo Uribe <lu...@gmail.com>
>>
>>> Hi
>>>
>>> 2013/11/24 Thomas Andraschko <an...@gmail.com>
>>>
>>>> Hi Leo,
>>>>
>>>>  By default all the code in UIComponentBase is already in place, so if
>>>>> all components extend from UIComponentBase everything will work just fine
>>>>
>>>>
>>>> cool, perfect!
>>>>
>>>> What about Behaviors or ActionListeners like:
>>>>
>>>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/component/collector/Collector.java
>>>>
>>>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java
>>>>
>>>> Will they work correctly?
>>>>
>>>
>>> Yes, because the related variables are stored into the state, so if they
>>> change, saveState(...) will return non null and in the worst case the
>>> component will be replaced with a new one.
>>>
>>> The ideal is the attached objects (Collector) implements
>>> PartialStateHolder instead StateHolder. The reason is the hack involves
>>> save the state when markInitialState(...) was called and when a hard reset
>>> is done, reuse that information and restore the state of the component or
>>> attached object like it was when the view was built by first time. But if
>>> that is not done, the algorithm just replace the component with a new one
>>> and problem solved.
>>>
>>> The tricky part are those variables that are not part of the state buy
>>> plays some role, because there is no way to know they are there. For
>>> example the dataModelMap in UIData, but the examples out there are very
>>> few.
>>>
>>>
>>>> All other components in PrimeFaces just use the StateHelper. So it
>>>> should be fine.
>>>>
>>>>
>>> If saveState(...) is overriden, there is a chance that some additional
>>> lines are required.
>>>
>>> Note we still have a lot of work to do, but the evidence we have suggest
>>> we should at least give another try and see what happens.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>
>>>> Regards,
>>>> Thomas
>>>>
>>>>
>>>>
>>>
>>
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Martin Kočí <ma...@gmail.com>]

Hi,

+1 for this feature in core 2.2.

Regards,

Kocicak


2013/11/24 Thomas Andraschko <an...@gmail.com>

> Perfect. Thanks for Info.
>
> So +1 from my side.
>
>
> 2013/11/24 Leonardo Uribe <lu...@gmail.com>
>
>> Hi
>>
>> 2013/11/24 Thomas Andraschko <an...@gmail.com>
>>
>>> Hi Leo,
>>>
>>>  By default all the code in UIComponentBase is already in place, so if
>>>> all components extend from UIComponentBase everything will work just fine
>>>
>>>
>>> cool, perfect!
>>>
>>> What about Behaviors or ActionListeners like:
>>>
>>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/component/collector/Collector.java
>>>
>>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java
>>>
>>> Will they work correctly?
>>>
>>
>> Yes, because the related variables are stored into the state, so if they
>> change, saveState(...) will return non null and in the worst case the
>> component will be replaced with a new one.
>>
>> The ideal is the attached objects (Collector) implements
>> PartialStateHolder instead StateHolder. The reason is the hack involves
>> save the state when markInitialState(...) was called and when a hard reset
>> is done, reuse that information and restore the state of the component or
>> attached object like it was when the view was built by first time. But if
>> that is not done, the algorithm just replace the component with a new one
>> and problem solved.
>>
>> The tricky part are those variables that are not part of the state buy
>> plays some role, because there is no way to know they are there. For
>> example the dataModelMap in UIData, but the examples out there are very
>> few.
>>
>>
>>> All other components in PrimeFaces just use the StateHelper. So it
>>> should be fine.
>>>
>>>
>> If saveState(...) is overriden, there is a chance that some additional
>> lines are required.
>>
>> Note we still have a lot of work to do, but the evidence we have suggest
>> we should at least give another try and see what happens.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>>> Regards,
>>> Thomas
>>>
>>>
>>>
>>
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Thomas Andraschko <an...@gmail.com>]

Perfect. Thanks for Info.

So +1 from my side.


2013/11/24 Leonardo Uribe <lu...@gmail.com>

> Hi
>
> 2013/11/24 Thomas Andraschko <an...@gmail.com>
>
>> Hi Leo,
>>
>>  By default all the code in UIComponentBase is already in place, so if
>>> all components extend from UIComponentBase everything will work just fine
>>
>>
>> cool, perfect!
>>
>> What about Behaviors or ActionListeners like:
>>
>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/component/collector/Collector.java
>>
>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java
>>
>> Will they work correctly?
>>
>
> Yes, because the related variables are stored into the state, so if they
> change, saveState(...) will return non null and in the worst case the
> component will be replaced with a new one.
>
> The ideal is the attached objects (Collector) implements
> PartialStateHolder instead StateHolder. The reason is the hack involves
> save the state when markInitialState(...) was called and when a hard reset
> is done, reuse that information and restore the state of the component or
> attached object like it was when the view was built by first time. But if
> that is not done, the algorithm just replace the component with a new one
> and problem solved.
>
> The tricky part are those variables that are not part of the state buy
> plays some role, because there is no way to know they are there. For
> example the dataModelMap in UIData, but the examples out there are very
> few.
>
>
>> All other components in PrimeFaces just use the StateHelper. So it should
>> be fine.
>>
>>
> If saveState(...) is overriden, there is a chance that some additional
> lines are required.
>
> Note we still have a lot of work to do, but the evidence we have suggest
> we should at least give another try and see what happens.
>
> regards,
>
> Leonardo Uribe
>
>
>> Regards,
>> Thomas
>>
>>
>>
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Leonardo Uribe <lu...@gmail.com>]

Hi

2013/11/24 Thomas Andraschko <an...@gmail.com>

> Hi Leo,
>
> By default all the code in UIComponentBase is already in place, so if all
>> components extend from UIComponentBase everything will work just fine
>
>
> cool, perfect!
>
> What about Behaviors or ActionListeners like:
>
> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/component/collector/Collector.java
>
> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java
>
> Will they work correctly?
>

Yes, because the related variables are stored into the state, so if they
change, saveState(...) will return non null and in the worst case the
component will be replaced with a new one.

The ideal is the attached objects (Collector) implements PartialStateHolder
instead StateHolder. The reason is the hack involves save the state when
markInitialState(...) was called and when a hard reset is done, reuse that
information and restore the state of the component or attached object like
it was when the view was built by first time. But if that is not done, the
algorithm just replace the component with a new one and problem solved.

The tricky part are those variables that are not part of the state buy
plays some role, because there is no way to know they are there. For
example the dataModelMap in UIData, but the examples out there are very
few.


> All other components in PrimeFaces just use the StateHelper. So it should
> be fine.
>
>
If saveState(...) is overriden, there is a chance that some additional
lines are required.

Note we still have a lot of work to do, but the evidence we have suggest we
should at least give another try and see what happens.

regards,

Leonardo Uribe


> Regards,
> Thomas
>
>
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Thomas Andraschko <an...@gmail.com>]

Hi Leo,

By default all the code in UIComponentBase is already in place, so if all
> components extend from UIComponentBase everything will work just fine


cool, perfect!

What about Behaviors or ActionListeners like:
http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/component/collector/Collector.java
http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java

Will they work correctly?
All other components in PrimeFaces just use the StateHelper. So it should
be fine.

Regards,
Thomas

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Leonardo Uribe <lu...@gmail.com>]

Hi Thomas

2013/11/23 Thomas Andraschko <an...@gmail.com>

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

It is something trivial. By default all the code in UIComponentBase is
already in place, so if all components extend from UIComponentBase
everything will work just fine. In some special cases where there are
components which variables outside StateHelper we need to add the ability
to do a hard/soft reset. For example this is the code that will be on UIData

    public Object saveState(FacesContext context)
    {
        if (context.getViewRoot() != null)
        {
            if (context.getViewRoot().getResetSaveStateMode() ==
RESET_MODE_SOFT)
            {
                _dataModelMap.clear();
                _isValidChilds=true;
                _rowTransientStates.clear();
            }
            if (context.getViewRoot().getResetSaveStateMode() ==
RESET_MODE_HARD)
            {
                _dataModelMap.clear();
                _isValidChilds=true;
                _rowTransientStates.clear();
                _rowStates.clear();
                _rowDeltaStates.clear();
            }
        }
        /*** continue with state saving ***/
        /*** ...... ***/
    }

Basically the idea is reinitialize the state of the component to a state
like it is being created by first time.



> Would it be possible that components are still 100% compatible with
> mojarra without changes?
>
>
Of course, since the idea is just check for an attribute in UIViewRoot
called "oam.view.resourceDependencyUniqueId" when saveState(...) is called
for a component, if the attribute is not set, nothing will happen and
things will work as usual.

Note the basic idea behind this technique is take advantage of the partial
state saving algorithm and use it to check if a view can be reused or not,
but in some special cases like UIData, not all information related to the
component state is stored in StateHelper. That's the reason why the
detection technique is not 100% fail safe.

regards,

Leonardo Uribe


> Regards,
> Thomas
>
>
>
> 2013/11/23 Leonardo Uribe <lu...@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>
>>
>> ____________________________
>>
>
>

Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x

[Thomas Andraschko <an...@gmail.com>]

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 <lu...@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>
>
> ____________________________
>