Hi
EB>> I understand and acknowledge your concern. The main user-level
EB>> documentation for this will be on the "transient" attribute on <f:view>.
EB>> There I will place a prominent warning that this feature will not work
EB>> with @ViewScoped managed beans.
EB>>
EB>> Is that sufficient to win at least your acquiescence, Leonardo?
Yes, a warning is enough. The important is be clear about the consequences
of use the attribute, to prevent people ask why this does not work over and
over in the future.
KM>> We also need to be clear about how this really helps. It's not a huge
KM>> performance boost for request processing, but it could have a big
KM>> effect on memory usage. And, in some cases, it makes development
KM>> easier.
Let's be clear about this:
- It will not provide a performance boost because a flat tree traversal over
components and the check for state is fast compared with other things that
impacts performance. To get a performance boost we need a view pool like
the one proposed, that exchange the time spent building the view with
the time spent in checking the view integrity and store/retrieve the view
from a lock free fast pool (already done).
- It will not have any impact over memory usage, because the view is built at
every request. To get the lowest possible memory usage we need a view pool
like the one proposed, that reuse views across request, but does not conflict
with the GC using soft/weak references (already done).
- It will have a very tiny effect over session size. Why? because PSS is
already doing a good job in that part. Note things are not the same between
Mojarra and MyFaces, so the numbers are different for each implementation.
If you want to have an idea take a look at the comparison last year between
JSF 2 and Wicket. There is a graph that shows the retained size in
memory per session, and the important point is that we can make the
view size very small and in that sense keep session size very small even
storing many views inside session.
The only case where this could have any effect is if you have something
like this:
<ui:include ="#{mybean.dynInclude}"/>
because the dynamic part needs to be saved fully, but I fixed that in MyFaces,
so right now it saves only the result of the EL expression as delta. So I
suppose views like this will have some benefit using Mojarra, but for
MyFaces the impact over session size will be minimal.
In conclusion it is clear in the long term the view pool strategy is
the way to go,
but it requires some work and time to get it done. That is of course, if the
benefits outweigh the complexity involved.
For now the idea "will be on the fridge", waiting for an opportunity.
But please go ahead with the "transient" attribute on f:view idea, because
after all, the changes are minimal and can be done in no time.
regards,
Leonardo Uribe
2013/2/27 Kito Mann <kito.mann_at_virtua.com>:
> We also need to be clear about how this really helps. It's not a huge
> performance boost for request processing, but it could have a big effect on
> memory usage. And, in some cases, it makes development easier.
>
> ___
>
> Kito D. Mann | @kito99 | Author, JSF in Action
> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
> @jsfcentral
> +1 203-998-0403
>
> * JSF in Action Public Course - NYC - April 2-4:
> http://skillsmatter.com/course/java-jee/jsf-and-ajax
> * Listen to the Enterprise Java Newscast:
> http://blogs.jsfcentral.com/JSFNewscast/
> * JSFCentral Interviews Podcast:
> http://www.jsfcentral.com/resources/jsfcentralpodcasts/
> * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
>
>
> On Mon, Feb 25, 2013 at 3:37 PM, Edward Burns <edward.burns_at_oracle.com>
> wrote:
>>
>> Hello Volunteers,
>>
>> You may have seen Manfred Riem's blog entry about stateless JSF. [1] I
>> wonder what you think about adding this for 2.2? Here are the spec
>> changes we would need for this minimal, yet effective approach.
>>
>> * Expose existing transient attribute on UIComponent on VDLDoc for
>> <f:view>.
>>
>> The text of the attribute will be based on UIComponent.isTransient():
>>
>> If true, the component (and therefore the children of the component)
>> must not participate in state saving or restoring.
>>
>> * In section 7.7.2.8 ViewDeclarationLanguage.restoreView(), change the
>> text to be the following.
>>
>> The JSP implementation must:
>>
>> [include the existing text of the section.]
>>
>> The Facelet implementation must:
>>
>> Call ResponseStateManager.isStateless(). If true, take the
>> following action (I will put this in English rather than code).
>>
>> ViewDeclarationLanguage vdl =
>> vdlFactory.getViewDeclarationLanguage(viewId);
>> viewRoot = vdl.createView(context, viewId);
>> @@ -543,9 +547,9 @@
>> ViewDeclarationLanguage vdl =
>> vdlFactory.getViewDeclarationLanguage(viewId);
>> viewRoot = vdl.getViewMetadata(context,
>> viewId).createMetadataView(context);
>> context.setViewRoot(viewRoot);
>>
>> and return, otherwise [...include existing text of the section].
>>
>> * In ResponseStateManager.writeState(), if the UIViewRoot is transient,
>> take impl specific action to make it so the call to
>> ResponseStateManager.isStateless() during the the next call, from
>> ViewDeclarationLanguage.restoreView(), returns true.
>>
>> * Spec for new method ResponseStateManager.isStateless(). If the
>> preceding writeState() was stateless, return true. If the preceding
>> writeState() was statefull return false, otherwise throw
>> IllegalStateException.
>>
>> Thanks,
>>
>> Ed
>>
>>
>> [1]
>> http://weblogs.java.net/blog/mriem/archive/2013/02/08/jsf-going-stateless
>>
>> --
>
>