[jira] [Commented] (MYFACES-3782) Random JSF error: no saved view state could be found
[ https://issues.apache.org/jira/browse/MYFACES-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777257#comment-13777257 ] Leonardo Uribe commented on MYFACES-3782: - This issue is well understood and it happens because if the server is restarted or the application is redeployed, a new encryption key is generated by default. The solution is generate your own key and set it up in your web.xml file. In that way, MyFaces will use the same key at all times. See http://wiki.apache.org/myfaces/Secure_Your_Application This issue will be closed as not a problem. It is just too obvious. Random JSF error: no saved view state could be found Key: MYFACES-3782 URL: https://issues.apache.org/jira/browse/MYFACES-3782 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.10, 2.1.12 Environment: Apache Tomee 1.5.2 and 1.6.0-2013.09.20 dev Reporter: Mircea Assignee: Leonardo Uribe All description, in a nice format, is here: http://stackoverflow.com/questions/18992241/random-jsf-error-no-saved-view-state-could-be-found -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3782) Random JSF error: no saved view state could be found
[ https://issues.apache.org/jira/browse/MYFACES-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777262#comment-13777262 ] Mircea commented on MYFACES-3782: - Hi! I didn't say that it doesn't work after restart/redeploy. It just doesn't work randomly. I have the following parameter in web.xml, therefore there's no problem with redeploy/restart etc. context-param param-nameorg.apache.myfaces.USE_ENCRYPTION/param-name param-valuefalse/param-value /context-param So...the bug is still there. Random JSF error: no saved view state could be found Key: MYFACES-3782 URL: https://issues.apache.org/jira/browse/MYFACES-3782 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.10, 2.1.12 Environment: Apache Tomee 1.5.2 and 1.6.0-2013.09.20 dev Reporter: Mircea Assignee: Leonardo Uribe All description, in a nice format, is here: http://stackoverflow.com/questions/18992241/random-jsf-error-no-saved-view-state-could-be-found -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (MYFACES-3782) Random JSF error: no saved view state could be found
[ https://issues.apache.org/jira/browse/MYFACES-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mircea reopened MYFACES-3782: - Not related to context-param param-nameorg.apache.myfaces.USE_ENCRYPTION/param-name param-valuefalse/param-value /context-param Random JSF error: no saved view state could be found Key: MYFACES-3782 URL: https://issues.apache.org/jira/browse/MYFACES-3782 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.10, 2.1.12 Environment: Apache Tomee 1.5.2 and 1.6.0-2013.09.20 dev Reporter: Mircea Assignee: Leonardo Uribe All description, in a nice format, is here: http://stackoverflow.com/questions/18992241/random-jsf-error-no-saved-view-state-could-be-found -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3782) Random JSF error: no saved view state could be found
[ https://issues.apache.org/jira/browse/MYFACES-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777302#comment-13777302 ] Leonardo Uribe commented on MYFACES-3782: - I have checked again the description and this is not an issue related to MyFaces. Instead there is something wrong in your application. This bug tracker should be used only when there is hard evidence of a bug. Before that, use the user mailing list to discuss the problem. I'm afraid I should close this issue again, because without a test case that can reproduce the issue there is no further advance from here. Random JSF error: no saved view state could be found Key: MYFACES-3782 URL: https://issues.apache.org/jira/browse/MYFACES-3782 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.10, 2.1.12 Environment: Apache Tomee 1.5.2 and 1.6.0-2013.09.20 dev Reporter: Mircea Assignee: Leonardo Uribe All description, in a nice format, is here: http://stackoverflow.com/questions/18992241/random-jsf-error-no-saved-view-state-could-be-found -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3733) Implement vdl.createComponent(...)
[
https://issues.apache.org/jira/browse/MYFACES-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3733.
-
Resolution: Fixed
Fix Version/s: 2.2.0
Assignee: Leonardo Uribe
Implement vdl.createComponent(...)
--
Key: MYFACES-3733
URL: https://issues.apache.org/jira/browse/MYFACES-3733
Project: MyFaces Core
Issue Type: Task
Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Fix For: 2.2.0
This is a difficult issue to do in JSF 2.2 . I have spent a long time to
solve this one, and given the complexity involved and since there is no
documentation anywhere about how this should work, I'll let the required
explanation here.
The idea is allow to include generated vdl fragments into pages
programatically. This includes normal components, composite components or
just fragments of markup. The method signature is this:
public UIComponent createComponent(FacesContext context, String taglibURI,
String tagName, MapString,Object attributes)
Some valid examples of this are:
// Normal component
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/html;,
outputText, attributes);
// Composite component
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/composite/testComposite;,
dynComp_1, attributes);
// Dynamic include
MapString, Object attributes = new HashMapString, Object();
attributes.put(src, /addSimpleIncludeVDL_1_1.xhtml);
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/facelets;,
include, attributes);
The javadoc does not suggest the dynamic include is valid, but I think users
expect these kind of stuff work.
Theoretically it sounds like something easy to do, but unfortunately it is
not. The reasons why this is so are:
- Facelets algorithm wraps html markup into UILeaf instances, which is a
special transient component. UILeaf instances are never saved or restored
from the component tree, but in some points of the algorithm (restore view
and before render response when vdl.buildView() is called) the component tree
is updated, adding or removing UILeaf instances.
- Facelets has an algorithm that require id generation to be stable,
otherwise a duplicate id exception may arise. A lot of effort has been done
to organize this part, and the current solution works very well. But in this
case, we need to generate unique ids that can be refreshed somehow.
- Facelets algorithm has an special logic to deal with dynamic sections like
the ones generated by c:if or
ui:include src=#{...} . Add facelets sections programatically could make
this algorithm fail, removing sections that should be.
- Facelets PSS algorithm needs to be taken into account too. The listener
that is used to register programmatic changes on the tree in
DefaultFaceletsStateManagementStrategy uses ComponentSupport.MARK_CREATED to
identify which component belongs to the component tree and which one was
added by outside. Add facelets sections programatically could make this
algorithm fail, because it could assume some sections of the tree does not
need to be saved fully, even if that's not true.
The issue in the spec is this:
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-611
At start the idea was to export FaceletFactory directly, but I told to the EG
that it was a bad idea by multiple reasons (That's a Pandora's Box). See:
https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/91
This previous message is useful too:
https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-06/message/18
After thinking and trying different strategies to overcome this issue, I
finally found the following solution:
- Use the compiler for generate a custom Facelet inline or on the fly. It
is not necessary to create an
xml document and then parse it, just generate the Tag class and pass it to
the compiler to generate an
Abstract Syntax Tree (AST), with the hierarchy of facelet TagHandler
instances.
- To solve the issue with UILeaf instances, the best is create a stateful
ComponentSystemEventListener that on restore view phase it compiles the
custom Facelet and apply it over the fragment. The ideal and only event to
attach the listener is PostRestoreStateEvent, but we need to add the code in
UIComponent.processEvent().
- In the case of a ui:include, if multiple components are returned, all of
them are grouped into a single
UIPanel. If the code returns one component, it returns that component.
- If the code generates a branch, or in other words, multiple nested
components, it should attach the
[jira] [Commented] (MYFACES-3733) Implement vdl.createComponent(...)
[
https://issues.apache.org/jira/browse/MYFACES-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777607#comment-13777607
]
Leonardo Uribe commented on MYFACES-3733:
-
I have finally committed the last issue to close this issue, with a lot of
junit tests. I have been thinking for a long time about how to do it and the
current solution split the problem in two:
- How to refresh when the component is under a binding, which means facelets
has the control.
- How to refresh when the component was added from somewhere else, which means
facelets base algorithm is not being executed right now.
Each one has its particular way to deal with the problem. In the binding
problem, the idea is just mark the component that holds the binding and use a
visitTree call to invoke the refresh algorithm. In the other scenario, a full
visitTree traversal is done, there is a listener attached listening to the
event and that's it. The trick from performance perspective is do not enable
this stuff if is not necessary.
In my opinion the algorithm is just great. At the end it was indeed a very
difficult problem to solve. We can close this issue as fixed, but there are
still some improvements to do in this part.
Implement vdl.createComponent(...)
--
Key: MYFACES-3733
URL: https://issues.apache.org/jira/browse/MYFACES-3733
Project: MyFaces Core
Issue Type: Task
Components: JSR-344
Reporter: Leonardo Uribe
This is a difficult issue to do in JSF 2.2 . I have spent a long time to
solve this one, and given the complexity involved and since there is no
documentation anywhere about how this should work, I'll let the required
explanation here.
The idea is allow to include generated vdl fragments into pages
programatically. This includes normal components, composite components or
just fragments of markup. The method signature is this:
public UIComponent createComponent(FacesContext context, String taglibURI,
String tagName, MapString,Object attributes)
Some valid examples of this are:
// Normal component
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/html;,
outputText, attributes);
// Composite component
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/composite/testComposite;,
dynComp_1, attributes);
// Dynamic include
MapString, Object attributes = new HashMapString, Object();
attributes.put(src, /addSimpleIncludeVDL_1_1.xhtml);
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/facelets;,
include, attributes);
The javadoc does not suggest the dynamic include is valid, but I think users
expect these kind of stuff work.
Theoretically it sounds like something easy to do, but unfortunately it is
not. The reasons why this is so are:
- Facelets algorithm wraps html markup into UILeaf instances, which is a
special transient component. UILeaf instances are never saved or restored
from the component tree, but in some points of the algorithm (restore view
and before render response when vdl.buildView() is called) the component tree
is updated, adding or removing UILeaf instances.
- Facelets has an algorithm that require id generation to be stable,
otherwise a duplicate id exception may arise. A lot of effort has been done
to organize this part, and the current solution works very well. But in this
case, we need to generate unique ids that can be refreshed somehow.
- Facelets algorithm has an special logic to deal with dynamic sections like
the ones generated by c:if or
ui:include src=#{...} . Add facelets sections programatically could make
this algorithm fail, removing sections that should be.
- Facelets PSS algorithm needs to be taken into account too. The listener
that is used to register programmatic changes on the tree in
DefaultFaceletsStateManagementStrategy uses ComponentSupport.MARK_CREATED to
identify which component belongs to the component tree and which one was
added by outside. Add facelets sections programatically could make this
algorithm fail, because it could assume some sections of the tree does not
need to be saved fully, even if that's not true.
The issue in the spec is this:
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-611
At start the idea was to export FaceletFactory directly, but I told to the EG
that it was a bad idea by multiple reasons (That's a Pandora's Box). See:
https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/91
This previous message is useful too:
https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-06/message/18
After thinking and trying different strategies to overcome this
[jira] [Commented] (MYFACES-3542) The render attribute of AjaxBehavior should support late value expression evaluation
[ https://issues.apache.org/jira/browse/MYFACES-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777657#comment-13777657 ] Dora Rajappan commented on MYFACES-3542: This particular behaviour of evaluating the render ids on the fly and then rendering those ids is not something the spec thought of implementing. The render attribute of AjaxBehavior should support late value expression evaluation Key: MYFACES-3542 URL: https://issues.apache.org/jira/browse/MYFACES-3542 Project: MyFaces Core Issue Type: New Feature Reporter: Bernd Bohmann Attachments: late-render-expression-0.png, late-render-expression-1.png, late-render-expression-2.png, late-render-expression-3.png, late-render-expression-4.png, late-render-expression.tgz The render attribute of AjaxBehavior should evaluated during post-back after 'Invoke Application' and before 'Render Response'. It's easly to add this feature with a own PartialViewContext. But there is no call to processPartial with 'Invoke Application'. The Phase 'Render Response' is too late if you are using c:if to skip components from the component tree. See attached example app and pictures. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3542) The render attribute of AjaxBehavior should support late value expression evaluation
[ https://issues.apache.org/jira/browse/MYFACES-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777676#comment-13777676 ] Dora Rajappan commented on MYFACES-3542: There is no problem with c:if component behaviour with visit algorithm also. Info2 component is in execute and when the checkbox was deselected subsequent ajax request test2 got skipped which is expected. If info2 is removed from execute ajax render wont skip test2 . Preference is clearly for ajax. I misunderstood the problem was with skipping components and not purely for late value expression evaluation for render attribute. The render attribute of AjaxBehavior should support late value expression evaluation Key: MYFACES-3542 URL: https://issues.apache.org/jira/browse/MYFACES-3542 Project: MyFaces Core Issue Type: New Feature Reporter: Bernd Bohmann Attachments: late-render-expression-0.png, late-render-expression-1.png, late-render-expression-2.png, late-render-expression-3.png, late-render-expression-4.png, late-render-expression.tgz The render attribute of AjaxBehavior should evaluated during post-back after 'Invoke Application' and before 'Render Response'. It's easly to add this feature with a own PartialViewContext. But there is no call to processPartial with 'Invoke Application'. The Phase 'Render Response' is too late if you are using c:if to skip components from the component tree. See attached example app and pictures. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2416) Provide default implementation for getRenderedFacetsAndChildren
Venkata Guddanti created TRINIDAD-2416: -- Summary: Provide default implementation for getRenderedFacetsAndChildren Key: TRINIDAD-2416 URL: https://issues.apache.org/jira/browse/TRINIDAD-2416 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Environment: trunk Reporter: Venkata Guddanti UIXComponent needs to provide default implementation of getRenderedFacetsAndChildren for cases where a UIXComponent subclass wants to restore the default implementation that one of its superclasses have overridden. The usecase is as follows: Currently UIXShowDetail short-circuits the processing of its children through getRenderedFacetsAndChildren when it is not disclosed. However its subclasses might want to processes certain facets even when it is not disclosed. In such cases the subclasses can override the getRenderedFacetsAndChildren and fallback to the default implementation which delegates to the renderer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2416) Provide default implementation for getRenderedFacetsAndChildren
[ https://issues.apache.org/jira/browse/TRINIDAD-2416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Venkata Guddanti updated TRINIDAD-2416: --- Status: Patch Available (was: Open) Provide default implementation for getRenderedFacetsAndChildren Key: TRINIDAD-2416 URL: https://issues.apache.org/jira/browse/TRINIDAD-2416 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Environment: trunk Reporter: Venkata Guddanti Original Estimate: 2h Remaining Estimate: 2h UIXComponent needs to provide default implementation of getRenderedFacetsAndChildren for cases where a UIXComponent subclass wants to restore the default implementation that one of its superclasses have overridden. The usecase is as follows: Currently UIXShowDetail short-circuits the processing of its children through getRenderedFacetsAndChildren when it is not disclosed. However its subclasses might want to processes certain facets even when it is not disclosed. In such cases the subclasses can override the getRenderedFacetsAndChildren and fallback to the default implementation which delegates to the renderer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2416) Provide default implementation for getRenderedFacetsAndChildren
[ https://issues.apache.org/jira/browse/TRINIDAD-2416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777998#comment-13777998 ] Venkata Guddanti commented on TRINIDAD-2416: Patch is for trinidad trunk Provide default implementation for getRenderedFacetsAndChildren Key: TRINIDAD-2416 URL: https://issues.apache.org/jira/browse/TRINIDAD-2416 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Environment: trunk Reporter: Venkata Guddanti Attachments: TRINIDAD-2416.patch Original Estimate: 2h Remaining Estimate: 2h UIXComponent needs to provide default implementation of getRenderedFacetsAndChildren for cases where a UIXComponent subclass wants to restore the default implementation that one of its superclasses have overridden. The usecase is as follows: Currently UIXShowDetail short-circuits the processing of its children through getRenderedFacetsAndChildren when it is not disclosed. However its subclasses might want to processes certain facets even when it is not disclosed. In such cases the subclasses can override the getRenderedFacetsAndChildren and fallback to the default implementation which delegates to the renderer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
