[jira] [Created] (MYFACES-3754) Update PartialViewContext and PartialResponseWriter to new spec
Leonardo Uribe created MYFACES-3754: --- Summary: Update PartialViewContext and PartialResponseWriter to new spec Key: MYFACES-3754 URL: https://issues.apache.org/jira/browse/MYFACES-3754 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe There are some special points in PartialViewContext and PartialResponseWriter that needs to be prefixed. For example, use writePreamble(...) , some lines to deal with ClientWindow and fix ViewState for portlet case. -- 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-3754) Update PartialViewContext and PartialResponseWriter to new spec
[ https://issues.apache.org/jira/browse/MYFACES-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3754. - Resolution: Fixed Fix Version/s: 2.2.0 Update PartialViewContext and PartialResponseWriter to new spec --- Key: MYFACES-3754 URL: https://issues.apache.org/jira/browse/MYFACES-3754 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.2.0 There are some special points in PartialViewContext and PartialResponseWriter that needs to be prefixed. For example, use writePreamble(...) , some lines to deal with ClientWindow and fix ViewState for portlet case. -- 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-3754) Update PartialViewContext and PartialResponseWriter to new spec
[ https://issues.apache.org/jira/browse/MYFACES-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13741667#comment-13741667 ] Leonardo Uribe commented on MYFACES-3754: - See http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1068 Update PartialViewContext and PartialResponseWriter to new spec --- Key: MYFACES-3754 URL: https://issues.apache.org/jira/browse/MYFACES-3754 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.2.0 There are some special points in PartialViewContext and PartialResponseWriter that needs to be prefixed. For example, use writePreamble(...) , some lines to deal with ClientWindow and fix ViewState for portlet case. -- 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] (MYFACES-3755) Show detail message on title of tooltip when showDetail is set or is available for h:message or h:messages
Leonardo Uribe created MYFACES-3755: --- Summary: Show detail message on title of tooltip when showDetail is set or is available for h:message or h:messages Key: MYFACES-3755 URL: https://issues.apache.org/jira/browse/MYFACES-3755 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe -- 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-3755) Show detail message on title of tooltip when showDetail is set or is available for h:message or h:messages
[ https://issues.apache.org/jira/browse/MYFACES-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13741704#comment-13741704 ] Leonardo Uribe commented on MYFACES-3755: - See https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1030 Show detail message on title of tooltip when showDetail is set or is available for h:message or h:messages -- Key: MYFACES-3755 URL: https://issues.apache.org/jira/browse/MYFACES-3755 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe -- 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] (MYFACES-3750) Allow to reference composite components directly from facelets taglib file using resource-id
Leonardo Uribe created MYFACES-3750: --- Summary: Allow to reference composite components directly from facelets taglib file using resource-id Key: MYFACES-3750 URL: https://issues.apache.org/jira/browse/MYFACES-3750 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Allow to reference composite components directly from facelets taglib file using resource-id -- 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-3750) Allow to reference composite components directly from facelets taglib file using resource-id
[ https://issues.apache.org/jira/browse/MYFACES-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3750. - Resolution: Fixed Fix Version/s: 2.2.0 Allow to reference composite components directly from facelets taglib file using resource-id --- Key: MYFACES-3750 URL: https://issues.apache.org/jira/browse/MYFACES-3750 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.2.0 Allow to reference composite components directly from facelets taglib file using resource-id -- 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] (MYFACES-3747) Implement new JSF 2.2 ViewScope specification
Leonardo Uribe created MYFACES-3747: --- Summary: Implement new JSF 2.2 ViewScope specification Key: MYFACES-3747 URL: https://issues.apache.org/jira/browse/MYFACES-3747 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe JSF 2.2 spec includes some changes related to view scope behavior: - There is a new CDI annotation javax.faces.view.ViewScoped - In UIViewRoot.getViewMap() javadoc it says: ... For reasons made clear in ViewScoped, this map must ultimately be stored in the session. For this reason, a true value for the create argument will force the session to be created with a call to ExternalContext.getSession(boolean). - Both @ViewScoped annotations javadoc include this: ... The runtime must ensure that any methods on the bean annotated with PostConstruct or PreDestroy are called when the scope begins and ends, respectively. Two circumstances can cause the scope to end. ... - ... In the session expiration case, the runtime must ensure that FacesContext.getCurrentInstance() returns a valid instance if it is called during the processing of the @PreDestroy annotated method. The set of methods on FacesContext that are valid to call in this circumstance is identical to those documented as valid to call this method during application startup or shutdown. On the ExternalContext returned from that FacesContext, all of the methods documented as valid to call this method during application startup or shutdown are valid to call. In addition, the method ExternalContext.getSessionMap() is also valid to call. ... -- 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-3747) Implement new JSF 2.2 ViewScope specification
[ https://issues.apache.org/jira/browse/MYFACES-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736479#comment-13736479 ] Leonardo Uribe commented on MYFACES-3747: - Committed prototype for this feature, taking into account the lessons learned from deltaspike WindowScope. There is still some missing details, like ensure proper processing of @PreDestroy annotation, but the structure of the solution and the code is good enough to commit it. Implement new JSF 2.2 ViewScope specification - Key: MYFACES-3747 URL: https://issues.apache.org/jira/browse/MYFACES-3747 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe JSF 2.2 spec includes some changes related to view scope behavior: - There is a new CDI annotation javax.faces.view.ViewScoped - In UIViewRoot.getViewMap() javadoc it says: ... For reasons made clear in ViewScoped, this map must ultimately be stored in the session. For this reason, a true value for the create argument will force the session to be created with a call to ExternalContext.getSession(boolean). - Both @ViewScoped annotations javadoc include this: ... The runtime must ensure that any methods on the bean annotated with PostConstruct or PreDestroy are called when the scope begins and ends, respectively. Two circumstances can cause the scope to end. ... - ... In the session expiration case, the runtime must ensure that FacesContext.getCurrentInstance() returns a valid instance if it is called during the processing of the @PreDestroy annotated method. The set of methods on FacesContext that are valid to call in this circumstance is identical to those documented as valid to call this method during application startup or shutdown. On the ExternalContext returned from that FacesContext, all of the methods documented as valid to call this method during application startup or shutdown are valid to call. In addition, the method ExternalContext.getSessionMap() is also valid to call. ... -- 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-3741) Implement CDI Flow Scope
[ https://issues.apache.org/jira/browse/MYFACES-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736481#comment-13736481 ] Leonardo Uribe commented on MYFACES-3741: - Committed prototype for this feature, taking into account the lessons learned from deltaspike WindowScope. There is still some review left to do, but for now the code is good enough. There is a clear separation for CDI code, so the jars will still work even if there is no CDI enabled. Two different implementations were done: one using CDI and other without CDI. Implement CDI Flow Scope Key: MYFACES-3741 URL: https://issues.apache.org/jira/browse/MYFACES-3741 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Reporter: Leonardo Uribe Implement CDI Flow Scope and add the necessary integration points into the implementation. -- 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-3745) org.apache.myfaces.view.facelets.impl.DefaultFaceletContext constructors are inconsistent
[ https://issues.apache.org/jira/browse/MYFACES-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730328#comment-13730328 ] Leonardo Uribe commented on MYFACES-3745: - That one is a long story. Even if both constructors looks similar, they are not the same. One is used when the top facelet is about to be built, and the second one is used as a wrapper to isolate the resolution of each facelet. By historical reasons the call to: faces.getAttributes().put(FaceletContext.FACELET_CONTEXT_KEY, this); was done there and came from facelets 1.1.x. But later I decided to do it right and move that call to the points where the constructor is called, to ensure the right context is available at each time. The line was never removed but the cleanup was done long time ago. In conclusion the constructors are not inconsistent as the title of the improvement (not bug) claims, but the line can be removed safely. org.apache.myfaces.view.facelets.impl.DefaultFaceletContext constructors are inconsistent - Key: MYFACES-3745 URL: https://issues.apache.org/jira/browse/MYFACES-3745 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.18, 2.1.12 Reporter: Paul Nicolucci Priority: Minor Attachments: MyFaces-3745.patch Original Estimate: 1h Remaining Estimate: 1h In MYFACES-3246 the following constructor was updated: DefaultFaceletContext(FacesContext faces, AbstractFacelet facelet, FaceletCompositionContext mctx) It no longer does the following: //Set FACELET_CONTEXT_KEY on FacesContext attribute map, to //reflect the current facelet context instance faces.getAttributes().put(FaceletContext.FACELET_CONTEXT_KEY, this); Setting the FACELET_CONTEXT_KEY is now done where ever the DefaultFaceletContext is created for instance in DefaultFacelet. DefaultFaceletContext ctxWrapper = new DefaultFaceletContext((DefaultFaceletContext)ctx, this, false); ctx.getFacesContext().getAttributes().put(FaceletContext.FACELET_CONTEXT_KEY, ctxWrapper); However, the other constructor which is actually being called above still sets the FACELET_CONTEXT_KEY and so it is set in the constructor and then set again directly after creation. //Update FACELET_CONTEXT_KEY on FacesContext attribute map, to //reflect the current facelet context instance ctx.getFacesContext().getAttributes().put(FaceletContext.FACELET_CONTEXT_KEY, this); I think this was just an oversight when fixing this bug. But I think we should clean this up and I'll provide the trivial patch that can be applied. -- 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-3741) Implement CDI Flow Scope
[ https://issues.apache.org/jira/browse/MYFACES-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722846#comment-13722846 ] Leonardo Uribe commented on MYFACES-3741: - Thanks for the comments. The problem is @FlowScoped belongs to javax.faces.flow package, so we can't do that change because we need to keep binary compatibility with the spec. Any other suggestion? Implement CDI Flow Scope Key: MYFACES-3741 URL: https://issues.apache.org/jira/browse/MYFACES-3741 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Reporter: Leonardo Uribe Implement CDI Flow Scope and add the necessary integration points into the implementation. -- 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-3741) Implement CDI Flow Scope
[ https://issues.apache.org/jira/browse/MYFACES-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722959#comment-13722959 ] Leonardo Uribe commented on MYFACES-3741: - Ok, I have checked WindowBeanHolder and I think it is a good idea to copy that code from deltaspike to myfaces and use it. I'll test it with the new javax.faces.view.ViewScope Implement CDI Flow Scope Key: MYFACES-3741 URL: https://issues.apache.org/jira/browse/MYFACES-3741 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Reporter: Leonardo Uribe Implement CDI Flow Scope and add the necessary integration points into the implementation. -- 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] (MYFACES-3743) redirectview-param... has been renamed to redirectredirect-param in navigation case
Leonardo Uribe created MYFACES-3743: --- Summary: redirectview-param... has been renamed to redirectredirect-param in navigation case Key: MYFACES-3743 URL: https://issues.apache.org/jira/browse/MYFACES-3743 Project: MyFaces Core Issue Type: Bug Components: JSR-314, JSR-344 Affects Versions: 2.1.12, 2.0.18 Reporter: Leonardo Uribe Assignee: Leonardo Uribe See: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-698 redirectview-param still works so the only change we need to do is add the proper rules into the parser. -- 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-3742) Implement @FlowDefinition annotation
[ https://issues.apache.org/jira/browse/MYFACES-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3742. - Resolution: Fixed Fix Version/s: 2.2.0 Assignee: Leonardo Uribe Implement @FlowDefinition annotation Key: MYFACES-3742 URL: https://issues.apache.org/jira/browse/MYFACES-3742 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.2.0 Implement @FlowDefinition cdi annotation, as described in the spec. I have found this annotation very tricky to implement. It is simple to do it using @Produces annotation, but the real trouble is we can't use CDI annotations inside myfaces implementation by the following reasons: - jar files without beans.xml will not be scanned. If we add the file inside myfaces jar, CDI will try to scan all classes inside the jar file, and some of them require optional dependencies. The final effect is CDI will start to throw errors. - In some cases, myfaces jars are not on WEB-INF/lib folder, and are just part of the default libraries of the server, so there is no reference to the files. The only option is use javax.enterprise.inject.spi.Producer, but Producer.getInjectionPoints() returns a SetInjectionPoint which usually are customized for the CDI implementation. So, we need to provide an implementation, but before that, we need to check how that part works to do not break CDI implementations. -- 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-3742) Implement @FlowDefinition annotation
[ https://issues.apache.org/jira/browse/MYFACES-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722051#comment-13722051 ] Leonardo Uribe commented on MYFACES-3742: - Committed solution for this issue. It seems the easiest way to do it is use a cdi Extension that register an application scope bean and use the annotation syntax to create the producer method. Then, the tricky part was use cdi to get the list of flow definitions. I tried with both weld and openwebbeans and in both cases it works. Implement @FlowDefinition annotation Key: MYFACES-3742 URL: https://issues.apache.org/jira/browse/MYFACES-3742 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Reporter: Leonardo Uribe Implement @FlowDefinition cdi annotation, as described in the spec. I have found this annotation very tricky to implement. It is simple to do it using @Produces annotation, but the real trouble is we can't use CDI annotations inside myfaces implementation by the following reasons: - jar files without beans.xml will not be scanned. If we add the file inside myfaces jar, CDI will try to scan all classes inside the jar file, and some of them require optional dependencies. The final effect is CDI will start to throw errors. - In some cases, myfaces jars are not on WEB-INF/lib folder, and are just part of the default libraries of the server, so there is no reference to the files. The only option is use javax.enterprise.inject.spi.Producer, but Producer.getInjectionPoints() returns a SetInjectionPoint which usually are customized for the CDI implementation. So, we need to provide an implementation, but before that, we need to check how that part works to do not break CDI implementations. -- 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-3741) Implement CDI Flow Scope
[ https://issues.apache.org/jira/browse/MYFACES-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722069#comment-13722069 ] Leonardo Uribe commented on MYFACES-3741: - I have committed a minimal implementation of FlowScope, just to identify the integration points and make things work. But I think we need some help here from a openwebbeans committer or someone involved with CDI to make this part properly. The main issue is how to deal with the passivation of the beans. In this moment, the beans are just put into session scope just like with flash scope, but it is known that CDI implementation like openwebbeans has some special code here. The big question is if we need to provide some kind of SPI interface to override the default implementation provided from myfaces code and put something better. This part still needs some review. Implement CDI Flow Scope Key: MYFACES-3741 URL: https://issues.apache.org/jira/browse/MYFACES-3741 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Reporter: Leonardo Uribe Implement CDI Flow Scope and add the necessary integration points into the implementation. -- 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-3691) Implement Faces Flows
[ https://issues.apache.org/jira/browse/MYFACES-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722073#comment-13722073 ] Leonardo Uribe commented on MYFACES-3691: - I have finally committed the solution I have been working on for this issue for a long time. There is still some details to be solved, but the current code is good enough to commit it. The biggest problem was resolve nested flows properly and define the base algorithm, splitting the problem into two: first resolve the navigation command and then execute the command calling flowHandler.transition() properly. The code still need a solution for FlowHandler.clientWindowTransition(). Implement Faces Flows - Key: MYFACES-3691 URL: https://issues.apache.org/jira/browse/MYFACES-3691 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Implement Faces Flows as described in JSF 2.2 spec. -- 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] (MYFACES-3739) @ResourceDependency annotation + JSF 1.2 state saving + c:if (dynamic section) creates components on each click (UIViewRoot grows)
[
https://issues.apache.org/jira/browse/MYFACES-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-3739:
Resolution: Fixed
Fix Version/s: 2.1.13
2.2.0
2.0.19
Assignee: Leonardo Uribe
Status: Resolved (was: Patch Available)
@ResourceDependency annotation + JSF 1.2 state saving + c:if (dynamic
section) creates components on each click (UIViewRoot grows)
--
Key: MYFACES-3739
URL: https://issues.apache.org/jira/browse/MYFACES-3739
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.1.12
Environment: myfaces 2.1.12
Tomcat 6.0.36
Reporter: Andrei Zhemaituk
Assignee: Leonardo Uribe
Fix For: 2.0.19, 2.2.0, 2.1.13
Attachments: MYFACES-3739-1.patch
The issue was initially reported against RichFaces:
https://issues.jboss.org/browse/RF-13025
But it does not look like it is anything wrong with RichFaces here.
The issue is reproducible with pure myfaces when partial state saving is
turned OFF e.g. with the following code (every second click on Toggle
button causes new UIOutput element to be inserted to the view tree):
{code}
h:form
h:commandButton value=Toggle action=#{bean.togglePanelShown}
f:ajax execute=@this render=group/
/h:commandButton
h:panelGroup id=group
c:if test=#{bean.panelShown}
!-- Any component with @ResourceDependency annotation. --
custom:componentWithResourceDependency/
/c:if
/h:panelGroup
/h:form
{code}
--
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-3728) javax.faces.partial.execute=@none still process javax.faces.source component
[ https://issues.apache.org/jira/browse/MYFACES-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13706311#comment-13706311 ] Leonardo Uribe commented on MYFACES-3728: - The code in the js side is perfect. There is no need of any changes in that part. But maybe we can update the server side code to behave in this part as Mojarra. I can't see any side effects doing this change, but it is clear primefaces js should comply with the spec anyway. javax.faces.partial.execute=@none still process javax.faces.source component Key: MYFACES-3728 URL: https://issues.apache.org/jira/browse/MYFACES-3728 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.10 Reporter: Thomas Andraschko i found a weird issue that if i use p:ajax on inputText with process=@none, the InputTextRenderer#decode method will be still invoked. This works fine with f:ajax in myfaces and mojarra. p:ajax only works expected on mojarra. The only difference i found is, that p:ajax sends the javax.faces.partial.execute param and f:ajax not. Here is a list with the post params (without my inputs): PrimeFaces: javax.faces.ViewState=N%2F6uUZMB9%2BPXSBTJVus5p6rncWDWwUAgQ9UIOweKuerVM0Z7 javax.faces.partial.ajax=true javax.faces.source=xxx javax.faces.partial.execute=%40none javax.faces.partial.render=%40none javax.faces.behavior.event=change javax.faces.partial.event=change form_SUBMIT=1 MyFaces: javax.faces.ViewState=EHCQlskNw%2BLXSBTJVus5pyzjdxWpT%2B72t7rvnK11Nffi10%2Bl javax.faces.partial.ajax=true javax.faces.source=xxx javax.faces.behavior.event=change javax.faces.partial.event=change javax.faces.windowId=2cc form_SUBMIT=1 form=form -- 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-3728) javax.faces.partial.execute=@none still process javax.faces.source component
[ https://issues.apache.org/jira/browse/MYFACES-3728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13703380#comment-13703380 ] Leonardo Uribe commented on MYFACES-3728: - Checking the jsdoc spec of jsf.ajax.request it says: ... If the keyword @none is present, do not create and send the post data argument javax.faces.partial.execute. ... later on: ... If the keyword @none is present, do not create and send the post data argument javax.faces.partial.render. ... MyFaces is doing it right. But it also says this: ... If the keyword @all is present, create the post data argument with the name javax.faces.partial.execute and the value @all ... So in theory it is valid to pass the keyword inside javax.faces.partial.execute and javax.faces.partial.render fields. I think it is a topic more related to interpretation. The spec is clear saying that is @none keyword is used, it is responsibility of the client behavior renderer to omit the request parameters. In this case and being strict with the spec, I think the fix should be done at primefaces, but I don't see any reason why don't allow the case in MyFaces. Probably it is a good idea, because in theory developers should be able to invent new keywords, and overriding PartialViewContext make things work. In my opinion, it is not a bug, but it looks more like a clarification over the possible allowed values for these two request parameters. I think we can fix it on the next version. javax.faces.partial.execute=@none still process javax.faces.source component Key: MYFACES-3728 URL: https://issues.apache.org/jira/browse/MYFACES-3728 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.10 Reporter: Thomas Andraschko i found a weird issue that if i use p:ajax on inputText with process=@none, the InputTextRenderer#decode method will be still invoked. This works fine with f:ajax in myfaces and mojarra. p:ajax only works expected on mojarra. The only difference i found is, that p:ajax sends the javax.faces.partial.execute param and f:ajax not. Here is a list with the post params (without my inputs): PrimeFaces: javax.faces.ViewState=N%2F6uUZMB9%2BPXSBTJVus5p6rncWDWwUAgQ9UIOweKuerVM0Z7 javax.faces.partial.ajax=true javax.faces.source=xxx javax.faces.partial.execute=%40none javax.faces.partial.render=%40none javax.faces.behavior.event=change javax.faces.partial.event=change form_SUBMIT=1 MyFaces: javax.faces.ViewState=EHCQlskNw%2BLXSBTJVus5pyzjdxWpT%2B72t7rvnK11Nffi10%2Bl javax.faces.partial.ajax=true javax.faces.source=xxx javax.faces.behavior.event=change javax.faces.partial.event=change javax.faces.windowId=2cc form_SUBMIT=1 form=form -- 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-3716) Implement h:inputFile
[ https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13703388#comment-13703388 ] Leonardo Uribe commented on MYFACES-3716: - We can't introduce a new public class (javax.faces.component.HttpPartWrapper), otherwise we will break binary compatibility. I prefer rewrite the code in _HtmlInputFile to do not depend on additional imports. It will be longer but it will not require a change over the base template that will be replicated across all classes. I think the content is ok, just we need to work out on the shape. I still think the wrapper can be moved to the decode() method of the renderer. Implement h:inputFile - Key: MYFACES-3716 URL: https://issues.apache.org/jira/browse/MYFACES-3716 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Attachments: inputFile4Jul.patch Implement h:inputFile as described in the spec -- 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] (TOMAHAWK-1664) t:selectBooleanCheckbox / Binding is not working after Mojarra update
[
https://issues.apache.org/jira/browse/TOMAHAWK-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697876#comment-13697876
]
Leonardo Uribe commented on TOMAHAWK-1664:
--
I think the bean definition:
@ManagedBean
public class MyBean {
doesn't have the scope defined. The effect is the bean is created each time a
reference is done and because than the binding becomes null. Try set the bean
to @RequestScope . That will do the trick.
I don't see any problem here, so I think we can close it as invalid or not a
problem.
t:selectBooleanCheckbox / Binding is not working after Mojarra update
-
Key: TOMAHAWK-1664
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1664
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.13, 1.1.14
Environment: GlassFish Server Open Source Edition 3.1.2.2 (build 5)
- Windows 7 (64 Bit) Oracle Java jdk1.7.0_15 (64 Bit)
- Oracle Linux Server release 5.5 OpenJDK 64-Bit Server VM (build
1.6.0-b09, mixed mode)
- Mojarra v2.1.23
- org.apache.myfaces.tomahawk:tomahawk20:1.1.13
- org.apache.myfaces.tomahawk:tomahawk20:1.1.14
- org.apache.myfaces.tomahawk:tomahawk21:1.1.14
Reporter: Michael D.
After updating Mojarra from v2.1.6 to v2.1.23 I'm facing the issue, that the
binding of t:selectBooleanCheckbox is not working.
JSF snippet:
--- SNIP ---
t:selectBooleanCheckbox
id=myId
forceId=true
value=#{myBean.myValue}
binding=#{myBean.myBinding}
styleClass=myClass/
h:inputText
id=anotherId
value=#{myBean.anotherValue}
validator=#{myBean.validate}
requiredMessage=#{msg['required']}
maxlength=100/
--- SNAP
Java snippet:
--- SNIP ---
@ManagedBean
public class MyBean {
private UIInput myBinding;
private boolean myValue;
private String anotherValue;
// ...
public UIInput getMyBinding() { return myBinding; }
public void setMyBinding(UIInput myBinding) { this.myBinding = myBinding;
}
public boolean isMyValue() { return myValue; }
public void setMyValue(boolean myValue) { this.myValue = myValue; }
public String getAnotherValue() { return anotherValue; }
public void setAnotherValue(String anotherValue) { this.anotherValue =
anotherValue; }
public void validate(FacesContext ctx, UIComponent comp, Object value)
throws ValidatorException {
if ((HtmlSelectBooleanCheckbox) myBinding.isSelected()) { //
--- myBinding is null
// ...
}
}
}
--- SNAP ---
I did debug:
1. Opening page
a) getMyBinding is called
b) setMyBinding is called with valid instance
2. Submit form
a) No call of getMyBinding/setMyBinding
b) validate is called --- myBinding is null
If I replace t:selectBooleanCheckbox by h:selectBooleanCheckbox:
1. Opening page
a) getMyBinding is called
b) setMyBinding is called with valid instance
2. Submit form
a) setMyBinding is called with valid instance
b) validate is called --- myBinding is valid
3. Next page is displayed
--
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] (MYFACES-3741) Implement CDI Flow Scope
Leonardo Uribe created MYFACES-3741: --- Summary: Implement CDI Flow Scope Key: MYFACES-3741 URL: https://issues.apache.org/jira/browse/MYFACES-3741 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Reporter: Leonardo Uribe Implement CDI Flow Scope and add the necessary integration points into the implementation. -- 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] (TOMAHAWK-1664) t:selectBooleanCheckbox / Binding is not working after Mojarra update
[
https://issues.apache.org/jira/browse/TOMAHAWK-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697903#comment-13697903
]
Leonardo Uribe commented on TOMAHAWK-1664:
--
I think if there is a problem, the one who blame is Mojarra. Tomahawk
implementation of t:selectBooleanCheckbox is just a normal component. There are
no special TagHandler implementations or anything strange that could cause a
problem.
The first thing to do is verify if the instance of MyBean does not change at
each request with a debugger (just look the instance number, it should be the
same for the entire request). When there is a submit, a new request is created,
but it is responsibility of facelets algorithm to restore the bindings
properly, using PostRestoreStateEvent. t:selectBooleanCheckbox don't override
processEvent() method so the call will be processed in the parent class (
UIComponent ).
Anyway, if there is a problem in Mojarra, there is no possible hack to do in
Tomahawk to make it work.
t:selectBooleanCheckbox / Binding is not working after Mojarra update
-
Key: TOMAHAWK-1664
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1664
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.13, 1.1.14
Environment: GlassFish Server Open Source Edition 3.1.2.2 (build 5)
- Windows 7 (64 Bit) Oracle Java jdk1.7.0_15 (64 Bit)
- Oracle Linux Server release 5.5 OpenJDK 64-Bit Server VM (build
1.6.0-b09, mixed mode)
- Mojarra v2.1.23
- org.apache.myfaces.tomahawk:tomahawk20:1.1.13
- org.apache.myfaces.tomahawk:tomahawk20:1.1.14
- org.apache.myfaces.tomahawk:tomahawk21:1.1.14
Reporter: Michael D.
After updating Mojarra from v2.1.6 to v2.1.23 I'm facing the issue, that the
binding of t:selectBooleanCheckbox is not working.
JSF snippet:
--- SNIP ---
t:selectBooleanCheckbox
id=myId
forceId=true
value=#{myBean.myValue}
binding=#{myBean.myBinding}
styleClass=myClass/
h:inputText
id=anotherId
value=#{myBean.anotherValue}
validator=#{myBean.validate}
requiredMessage=#{msg['required']}
maxlength=100/
--- SNAP
Java snippet:
--- SNIP ---
@ManagedBean
public class MyBean {
private UIInput myBinding;
private boolean myValue;
private String anotherValue;
// ...
public UIInput getMyBinding() { return myBinding; }
public void setMyBinding(UIInput myBinding) { this.myBinding = myBinding;
}
public boolean isMyValue() { return myValue; }
public void setMyValue(boolean myValue) { this.myValue = myValue; }
public String getAnotherValue() { return anotherValue; }
public void setAnotherValue(String anotherValue) { this.anotherValue =
anotherValue; }
public void validate(FacesContext ctx, UIComponent comp, Object value)
throws ValidatorException {
if ((HtmlSelectBooleanCheckbox) myBinding.isSelected()) { //
--- myBinding is null
// ...
}
}
}
--- SNAP ---
I did debug:
1. Opening page
a) getMyBinding is called
b) setMyBinding is called with valid instance
2. Submit form
a) No call of getMyBinding/setMyBinding
b) validate is called --- myBinding is null
If I replace t:selectBooleanCheckbox by h:selectBooleanCheckbox:
1. Opening page
a) getMyBinding is called
b) setMyBinding is called with valid instance
2. Submit form
a) setMyBinding is called with valid instance
b) validate is called --- myBinding is valid
3. Next page is displayed
--
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] (MYFACES-3742) Implement @FlowDefinition annotation
Leonardo Uribe created MYFACES-3742: --- Summary: Implement @FlowDefinition annotation Key: MYFACES-3742 URL: https://issues.apache.org/jira/browse/MYFACES-3742 Project: MyFaces Core Issue Type: Sub-task Components: JSR-344 Reporter: Leonardo Uribe Implement @FlowDefinition cdi annotation, as described in the spec. I have found this annotation very tricky to implement. It is simple to do it using @Produces annotation, but the real trouble is we can't use CDI annotations inside myfaces implementation by the following reasons: - jar files without beans.xml will not be scanned. If we add the file inside myfaces jar, CDI will try to scan all classes inside the jar file, and some of them require optional dependencies. The final effect is CDI will start to throw errors. - In some cases, myfaces jars are not on WEB-INF/lib folder, and are just part of the default libraries of the server, so there is no reference to the files. The only option is use javax.enterprise.inject.spi.Producer, but Producer.getInjectionPoints() returns a SetInjectionPoint which usually are customized for the CDI implementation. So, we need to provide an implementation, but before that, we need to check how that part works to do not break CDI implementations. -- 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-3739) @ResourceDependency annotation + JSF 1.2 state saving + c:if (dynamic section) creates components on each click (UIViewRoot grows)
[
https://issues.apache.org/jira/browse/MYFACES-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13693981#comment-13693981
]
Leonardo Uribe commented on MYFACES-3739:
-
Really it is expected to have more than one reference to the same resource in
those cases.
The problem is the complexity involved in do a check for uniqueness in that
place. If there is such check, we need to do some calculations and comparisons,
and at the end, more CPU will be used, which can lead to a degradation in
performance.
The algorithm as is will work better if we serialize the classes. Other
option that comes to my mind is use the string representation of the class
name. It could save some bytes, because after taking a look about what's being
serialized, the class name is included too. I think it is a good idea to change
a bit that part.
What's important is have the confirmation that the fix proposed solves the
problem. Thanks for check it. I'll commit the updated solution soon.
@ResourceDependency annotation + JSF 1.2 state saving + c:if (dynamic
section) creates components on each click (UIViewRoot grows)
--
Key: MYFACES-3739
URL: https://issues.apache.org/jira/browse/MYFACES-3739
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.1.12
Environment: myfaces 2.1.12
Tomcat 6.0.36
Reporter: Andrei Zhemaituk
Attachments: MYFACES-3739-1.patch
The issue was initially reported against RichFaces:
https://issues.jboss.org/browse/RF-13025
But it does not look like it is anything wrong with RichFaces here.
The issue is reproducible with pure myfaces when partial state saving is
turned OFF e.g. with the following code (every second click on Toggle
button causes new UIOutput element to be inserted to the view tree):
{code}
h:form
h:commandButton value=Toggle action=#{bean.togglePanelShown}
f:ajax execute=@this render=group/
/h:commandButton
h:panelGroup id=group
c:if test=#{bean.panelShown}
!-- Any component with @ResourceDependency annotation. --
custom:componentWithResourceDependency/
/c:if
/h:panelGroup
/h:form
{code}
--
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] (MYFACES-3740) ResourceResolver this identifier applies for contracts too in JSF 2.2
Leonardo Uribe created MYFACES-3740: --- Summary: ResourceResolver this identifier applies for contracts too in JSF 2.2 Key: MYFACES-3740 URL: https://issues.apache.org/jira/browse/MYFACES-3740 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Doing some reviews in the code, I found these lines in JSF 2.2 section 5.6.2.5 : getValue() ... If property contains a single colon character ‘:’, treat the content before the ‘:’ as the libraryName and the content after the ‘:’ as the resourceName and pass both to ResourceHandler.createResource( resourceName, libraryName). If the value of libraryName is the literal string “this” (without the quotes), discover the library name of the current resource (or the contract name of the current resource, the two are mutually exclusive) and replace “this” with that library name (or contract name) before calling ResourceHandler.createResource(). In the case of resource library contracts, libraryName will actually be the contract name. If property contains more than one colon character ‘:’, throw a localized ELException, including property ... In JSF 2.0, this was used when el expression where inside composite components, but in this case this refers to the contract itself. -- 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-3740) ResourceResolver this identifier applies for contracts too in JSF 2.2
[ https://issues.apache.org/jira/browse/MYFACES-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13694182#comment-13694182 ] Leonardo Uribe commented on MYFACES-3740: - The problem with this issue is that to resolve this identifier it is necessary to setup the context. For example, if a css resource is being served, the resulting EL expressions that are evaluated must take the context into account. If the file is a simple template, this should refer to the current facelet template, but that's tricky because if the EL expression is evaluated outside facelets control, the reference is lost. ResourceResolver this identifier applies for contracts too in JSF 2.2 --- Key: MYFACES-3740 URL: https://issues.apache.org/jira/browse/MYFACES-3740 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Doing some reviews in the code, I found these lines in JSF 2.2 section 5.6.2.5 : getValue() ... If property contains a single colon character ‘:’, treat the content before the ‘:’ as the libraryName and the content after the ‘:’ as the resourceName and pass both to ResourceHandler.createResource( resourceName, libraryName). If the value of libraryName is the literal string “this” (without the quotes), discover the library name of the current resource (or the contract name of the current resource, the two are mutually exclusive) and replace “this” with that library name (or contract name) before calling ResourceHandler.createResource(). In the case of resource library contracts, libraryName will actually be the contract name. If property contains more than one colon character ‘:’, throw a localized ELException, including property ... In JSF 2.0, this was used when el expression where inside composite components, but in this case this refers to the contract itself. -- 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-3724) MyFaces 2.x : HtmlSelectManyListbox does not work, if value points Hibernate-managed collection (i.e. PersistentBag)
[ https://issues.apache.org/jira/browse/MYFACES-3724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13693023#comment-13693023 ] Leonardo Uribe commented on MYFACES-3724: - I don't think we can do something in this part. A LazyInitializationException usually is related to the persistent layer used (I suppose in this case is openwebbeans). The code is in that place is correct and has been studied for a long time, so in my opinion we can close this issue as not a bug or invalid. MyFaces 2.x : HtmlSelectManyListbox does not work, if value points Hibernate-managed collection (i.e. PersistentBag) Key: MYFACES-3724 URL: https://issues.apache.org/jira/browse/MYFACES-3724 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.11 Reporter: Alexey Shakov Priority: Trivial _SharedRendererUtils.getConvertedUISelectManyValue(...) creates an instance of PersistentBag at line 268. LazyInitializationException comes later in UISelectMany._createItemValuesIterator at line 436. Works with Myfaces 1.2.12 -- 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] (MYFACES-3739) @ResourceDependency annotation + JSF 1.2 state saving + c:if (dynamic section) creates components on each click (UIViewRoot grows)
[
https://issues.apache.org/jira/browse/MYFACES-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-3739:
Status: Patch Available (was: Open)
@ResourceDependency annotation + JSF 1.2 state saving + c:if (dynamic
section) creates components on each click (UIViewRoot grows)
--
Key: MYFACES-3739
URL: https://issues.apache.org/jira/browse/MYFACES-3739
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.1.12
Environment: myfaces 2.1.12
Tomcat 6.0.36
Reporter: Andrei Zhemaituk
Attachments: MYFACES-3739-1.patch
The issue was initially reported against RichFaces:
https://issues.jboss.org/browse/RF-13025
But it does not look like it is anything wrong with RichFaces here.
The issue is reproducible with pure myfaces when partial state saving is
turned OFF e.g. with the following code (every second click on Toggle
button causes new UIOutput element to be inserted to the view tree):
{code}
h:form
h:commandButton value=Toggle action=#{bean.togglePanelShown}
f:ajax execute=@this render=group/
/h:commandButton
h:panelGroup id=group
c:if test=#{bean.panelShown}
!-- Any component with @ResourceDependency annotation. --
custom:componentWithResourceDependency/
/c:if
/h:panelGroup
/h:form
{code}
--
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-3739) @ResourceDependency annotation + JSF 1.2 state saving + c:if (dynamic section) creates components on each click (UIViewRoot grows)
[
https://issues.apache.org/jira/browse/MYFACES-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13693033#comment-13693033
]
Leonardo Uribe commented on MYFACES-3739:
-
I have attached a working solution for this issue.
The idea is just store the inspected class in a component attribute, in cases
where no PSS is used, or there is a programmatic addition, or
refreshTransientBuild with preserveState option is used.
Later, on restore view phase, we can just inspect the facets that are used to
store added resources and scan for this attribute. The idea is resfresh
RequestViewContext, so the classes that has been already inspected by
@ResourceDependency annotation will not be scanned anymore.
It has a very small hit in performance, but I consider this solution relevant
because with JSF 2.2 vdl.createComponent(...) stuff there are more chances to
found this problem again in the future.
I have measured the size of a serialized class reference and is relatively
small (80-150 bytes),
It could be good if someone can confirm if the attached patch works or not, so
we can commit it and make it available on the next release.
@ResourceDependency annotation + JSF 1.2 state saving + c:if (dynamic
section) creates components on each click (UIViewRoot grows)
--
Key: MYFACES-3739
URL: https://issues.apache.org/jira/browse/MYFACES-3739
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.1.12
Environment: myfaces 2.1.12
Tomcat 6.0.36
Reporter: Andrei Zhemaituk
Attachments: MYFACES-3739-1.patch
The issue was initially reported against RichFaces:
https://issues.jboss.org/browse/RF-13025
But it does not look like it is anything wrong with RichFaces here.
The issue is reproducible with pure myfaces when partial state saving is
turned OFF e.g. with the following code (every second click on Toggle
button causes new UIOutput element to be inserted to the view tree):
{code}
h:form
h:commandButton value=Toggle action=#{bean.togglePanelShown}
f:ajax execute=@this render=group/
/h:commandButton
h:panelGroup id=group
c:if test=#{bean.panelShown}
!-- Any component with @ResourceDependency annotation. --
custom:componentWithResourceDependency/
/c:if
/h:panelGroup
/h:form
{code}
--
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-3716) Implement h:inputFile
[ https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13691946#comment-13691946 ] Leonardo Uribe commented on MYFACES-3716: - I have found one bug in org.apache.myfaces.view.facelets.tag.jsf.html.HtmlLibrary . The renderer type should be javax.faces.File, not javax.faces.InputFile. Forget about javax.faces.InputFile as renderer type. I don't think the duplicate file is necessary. Implement h:inputFile - Key: MYFACES-3716 URL: https://issues.apache.org/jira/browse/MYFACES-3716 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Attachments: inputfile17Jun2013.patch, xhtmlAndjspxnew.patch Implement h:inputFile as described in the spec -- 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-3716) Implement h:inputFile
[ https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13691434#comment-13691434 ] Leonardo Uribe commented on MYFACES-3716: - Jsp mode is deprecated. No need to bother about read jspx files using the old jsp algorithm, because the new approach is use facelets algorithm to read jspx files (see JSF 2.1 appendix A 1.2.1.1 The facelets-processing element) . Theorically, jsp stuff should not change. I remember a discussion long time ago, and the suggested solution was precisely change some lines in UIComponentELTag, but the position was deprecate jsp. Implement h:inputFile - Key: MYFACES-3716 URL: https://issues.apache.org/jira/browse/MYFACES-3716 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Attachments: inputfile17Jun2013.patch, xhtmlAndjspx.patch Implement h:inputFile as described in the spec -- 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-3739) @ResourceDependency annotation + JSF 1.2 state saving + c:if (dynamic section) creates components on each click (UIViewRoot grows)
[
https://issues.apache.org/jira/browse/MYFACES-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13691649#comment-13691649
]
Leonardo Uribe commented on MYFACES-3739:
-
I have changed the title of the issue to be more descriptive about the
necessary conditions to make it happen. More than a memory leak is a state
saving leak that under some conditions could cause a memory leak.
This is a known defect of the design done for @ResourceDependency annotation
and JSF 1.2 state saving. With partial state saving, all components of the tree
are recreated using Application.createComponent(), so the components added
using @ResourceDependency annotations are added too. Since those components are
recreated each time the view is build, there is no need to save them on the
state.
But things are different for JSF 1.2 state saving. In this case all instances
are saved with the state. There missing part is something that recalculate that
part at each request, but the current spec as is does not consider that.
Any solution that try to keep track of the relationship between the
@ResourceDependency and the component / renderer that originates it just
increase the state size too. The consideration is since the state does not grow
fast enough it is more optimal to keep things simple and let it as is, than try
a more complex solution that will put a constant big weight over the state.
Even so, a solution is feasible, but it will not be easy, because we need in
this part an algorithm with linear complexity, otherwise the performance will
be affected, at least with JSF 1.2 state saving. Note the conditions to
reproduce the problem are very rare.
One option that comes to my mind is with JSF 1.2 state saving scan UIViewRoot
facets and fill RequestViewContext properly, to ensure the dynamic part takes
into account the previous added references, and it that way, there will not be
duplicates. I need to think about that carefully, but at first view it could
work.
@ResourceDependency annotation + JSF 1.2 state saving + c:if (dynamic
section) creates components on each click (UIViewRoot grows)
--
Key: MYFACES-3739
URL: https://issues.apache.org/jira/browse/MYFACES-3739
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.1.12
Environment: myfaces 2.1.12
Tomcat 6.0.36
Reporter: Andrei Zhemaituk
The issue was initially reported against RichFaces:
https://issues.jboss.org/browse/RF-13025
But it does not look like it is anything wrong with RichFaces here.
The issue is reproducible with pure myfaces when partial state saving is
turned OFF e.g. with the following code (every second click on Toggle
button causes new UIOutput element to be inserted to the view tree):
{code}
h:form
h:commandButton value=Toggle action=#{bean.togglePanelShown}
f:ajax execute=@this render=group/
/h:commandButton
h:panelGroup id=group
c:if test=#{bean.panelShown}
!-- Any component with @ResourceDependency annotation. --
custom:componentWithResourceDependency/
/c:if
/h:panelGroup
/h:form
{code}
--
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] (MYFACES-3738) Add media attribute to h:outputStylesheet
Leonardo Uribe created MYFACES-3738: --- Summary: Add media attribute to h:outputStylesheet Key: MYFACES-3738 URL: https://issues.apache.org/jira/browse/MYFACES-3738 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe See http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-550 Just add the attribute to the renderer class, because there is no instance (uses UIOutput) -- 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-3738) Add media attribute to h:outputStylesheet
[ https://issues.apache.org/jira/browse/MYFACES-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3738. - Resolution: Fixed Fix Version/s: 2.2.0 Add media attribute to h:outputStylesheet - Key: MYFACES-3738 URL: https://issues.apache.org/jira/browse/MYFACES-3738 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.2.0 See http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-550 Just add the attribute to the renderer class, because there is no instance (uses UIOutput) -- 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-3683) Implement AjaxBehavior resetValues and delay
[ https://issues.apache.org/jira/browse/MYFACES-3683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13685679#comment-13685679 ] Leonardo Uribe commented on MYFACES-3683: - I have committed the part that goes for AjaxHandler. Thanks to Dora Rajappan for provide this patch. But I think there are still things to do, specially in UIViewRoot class. I have let the blank spaces, but I have not entered yet into the necessary details to make it work fully. It seems we require to do some modifications in UIOutput/UIInput class too. Implement AjaxBehavior resetValues and delay Key: MYFACES-3683 URL: https://issues.apache.org/jira/browse/MYFACES-3683 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Attachments: MYFACES-3683-delay1.patch, MYFACES-3683-delay2.patch, MYFACES-3683-delay3.patch, resetValues.patch Implement AjaxBehavior resetValues and delay as described in the spec. -- 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-3716) Implement h:inputFile
[ https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13685686#comment-13685686 ] Leonardo Uribe commented on MYFACES-3716: - I don't understand the question. Could you be more specific about it? Implement h:inputFile - Key: MYFACES-3716 URL: https://issues.apache.org/jira/browse/MYFACES-3716 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Attachments: inputfile17Jun2013.patch Implement h:inputFile as described in the spec -- 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-3736) Occasional ResourceHandlerImpl Error trying to load resource jsf.js with library javax.faces
[
https://issues.apache.org/jira/browse/MYFACES-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683320#comment-13683320
]
Leonardo Uribe commented on MYFACES-3736:
-
I think the problem is caused by your particular development environment. The
lines that shows the message are these:
425 catch (IOException e)
426 {
427 //TODO: Log using a localized message (which one?)
428 if (log.isLoggable(Level.SEVERE))
429 {
430 log.severe(Error trying to load resource +
resourceName
431 + with library + libraryName + :
432 + e.getMessage());
433 }
434
httpServletResponse.setStatus(HttpServletResponse.SC_NOT_FOUND);
435 }
The text sent suggest e.getMessage() is null, which is not common, but does not
suggest a bug.
I'm sure the code works as expected, otherwise we could have seen the problem
long time ago. My opinion is close this issue as invalid, but maybe it is a
good idea to include the exception in the call to log.severe (
log.log(Level.SEVERE, ... , e) ).
Occasional ResourceHandlerImpl Error trying to load resource jsf.js with
library javax.faces
Key: MYFACES-3736
URL: https://issues.apache.org/jira/browse/MYFACES-3736
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.10
Environment: Windows Server 2008 R2
Java 1.7.0_07
Apache Tomcat 7.0.39
Reporter: Moshe Elisha
From time to time I encountered the following error:
ERROR http-apr-80-exec-2 ResourceHandlerImpl:425: Error trying to load
resource jsf.js with library javax.faces :null
That is all I have. I can't tell what the exact request details or what is
the IOException.
Can you please also make it possible to log the IOException stacktrace?
Thanks.
--
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-3716) Implement h:inputFile
[ https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681211#comment-13681211 ] Leonardo Uribe commented on MYFACES-3716: - I have committed partially the patch. I think there is a misunderstanting between what should be done in decode() method and what should be done inside encodeXXX(). I have analyzed the solution and I think we should create a wrapper class to hold the real javax.servlet.http.Part, so when the component is saved into the state, do not serialize the real Part instance, which by definition could or not implement Serializable interface. The idea could be that the wrapper implements StateHolder or Serializable interface/transient variable. According to servlet spec 3.0 Part.write(...) method says this: ... A convenience method to write an uploaded part to disk. The client code is not concerned with whether or not the part is stored in memory, or on disk in a temporary location. They just want to write the uploaded part to a file. This method is not guaranteed to succeed if called more than once for the same part. This allows a particular implementation to use, for example, file renaming, where possible, rather than copying all of the underlying data, thus gaining a significant performance benefit. ... It is expected that once the file is sent, it should be used and not saved along with the tree. Other option is override submittedValue and value attributes to prevent store them in the component state. We should avoid override processRestoreState, because with the new algorithm introduced in JSF 2.0, there is no warrant about if the method will be called or not (a visit tree invocation do that job instead). The code inside the renderer does not follow what the spec says. The idea is check if the parent form has multipart encoding, not the incoming request, which is different. But I'm still thinking about how this component will work for ajax operations. I suppose the spec as is does not consider that, but I suppose we should make it work. Implement h:inputFile - Key: MYFACES-3716 URL: https://issues.apache.org/jira/browse/MYFACES-3716 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Attachments: inputfileCommentUpdated.patch, inputfileperfect.patch Implement h:inputFile as described in the spec -- 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-3735) NullPointerException in CompositeMetadataTargetImpl.init
[
https://issues.apache.org/jira/browse/MYFACES-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13680447#comment-13680447
]
Leonardo Uribe commented on MYFACES-3735:
-
First of all thanks for report this issue. I think it is a bug that could
happen when by casuality two threads are building the same composite component
at the same time.
This is one of those issues that cannot be reproduced, because the conditions
where this happens are very rare. In this case, once the composite component
BeanInfo instance is built, it will not appear never again.
The solution is just ensure the volatile variable _cachedBeanInfo is written at
the finally block inside CompositeComponentDefinitionTagHandler and use
tempBeanInfo to hold the bean temporally.
That should work, but I'm not 100% sure about that, so please give it a try and
let me know if that works or not. I'll commit the code so you can just take a
snapshot to try. Thanks for your help.
NullPointerException in CompositeMetadataTargetImpl.init
--
Key: MYFACES-3735
URL: https://issues.apache.org/jira/browse/MYFACES-3735
Project: MyFaces Core
Issue Type: Bug
Reporter: Ulf Liller
Attachments: MYFACES-3735.patch
In our application (MyFaces 2.1.10, RichFaces 4.2.2), the following exception
is sometimes (rarely) thrown when logging in. If that happens, it completely
breaks the app, all subsequent login attempts fail with the same exception.
{code}
java.lang.NullPointerException
at
org.apache.myfaces.view.facelets.tag.composite.CompositeMetadataTargetImpl.init(CompositeMetadataTargetImpl.java:58)
at
org.apache.myfaces.view.facelets.tag.composite.CompositeMetaRulesetImpl.init(CompositeMetaRulesetImpl.java:103)
at
org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler.createMetaRuleset(CompositeComponentResourceTagHandler.java:410)
at
org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler.setAttributes(CompositeComponentResourceTagHandler.java:401)
at
org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:113)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:237)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at
org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:294)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49)
at
org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:158)
at
org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57)
at
org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48)
at
org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:394)
at
org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:448)
at
org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:426)
at
org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:244)
at
org.apache.myfaces.view.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:217)
at
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at
org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:53)
at
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:294)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at
[jira] [Resolved] (MYFACES-3734) Implement @FacesComponent createTag, namespace and tagName attributes
[ https://issues.apache.org/jira/browse/MYFACES-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3734. - Resolution: Fixed Fix Version/s: 2.2.0 Assignee: Leonardo Uribe I have committed a solution for this one. I think it is ok, but maybe there is a minor problem because when creating a tag, you usually must have the renderer type. If null is passed, the tag handler will not be created correctly, so you need to find out which is the default renderer type. The easy way is create a dummy component and try to retrieve the value from getRendererType(). Implement @FacesComponent createTag, namespace and tagName attributes - Key: MYFACES-3734 URL: https://issues.apache.org/jira/browse/MYFACES-3734 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.2.0 The trick with this one is add proper metadata in FacesConfig class to identify which components has a component tag definition. The best is associate the componentType with the definition. When the configuration is read, this information goes to RuntimeConfig and finally facelets vdl grab this information and set up the compiler. In theory it should be something like the hierarchy of classes we have for FacesConfig, but for facelets, but since there is and there will be an stronger collaboration between jsf and facelets, it has more sense to put all related information into FacesConfig. -- 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-3716) Implement h:inputFile
[ https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678025#comment-13678025 ] Leonardo Uribe commented on MYFACES-3716: - I have some comments about the patch. - InputFile was removed, because it was a duplicate of _HtmlInputFile. In this case, it is better to preserve the current convention about file naming. - The code related to save/restore the state must be done directly in _HtmlInputFile. We cannot change the way UIComponentBase works, because it was already defined by the spec. I think the way to do it is use @JSFExcluded annotation. I need to take a look to see if it is working in core, because if not we could need to override the template. - It is not necessary to keep servlet 2.5 artifact, just replace it with 3.0. I'll do that. - I think the part that check for multipart/form-data could cause problems because not all request should be multipart/form-data, only the ones where it is necessary to decode or extract the file. A check will look better overriding decode() method. Implement h:inputFile - Key: MYFACES-3716 URL: https://issues.apache.org/jira/browse/MYFACES-3716 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Attachments: inputfileperfect.patch Implement h:inputFile as described in the spec -- 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] (MYFACES-3734) Implement @FacesComponent createTag, namespace and tagName attributes
Leonardo Uribe created MYFACES-3734: --- Summary: Implement @FacesComponent createTag, namespace and tagName attributes Key: MYFACES-3734 URL: https://issues.apache.org/jira/browse/MYFACES-3734 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe The trick with this one is add proper metadata in FacesConfig class to identify which components has a component tag definition. The best is associate the componentType with the definition. When the configuration is read, this information goes to RuntimeConfig and finally facelets vdl grab this information and set up the compiler. In theory it should be something like the hierarchy of classes we have for FacesConfig, but for facelets, but since there is and there will be an stronger collaboration between jsf and facelets, it has more sense to put all related information into FacesConfig. -- 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] (MYFACES-3733) Implement vdl.createComponent(...)
Leonardo Uribe created MYFACES-3733:
---
Summary: 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 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
listener to deal with UILeaf instances, if it just generates one component do
not do that because it is
not necessary.
- To solve the issue with the ids, just call UIViewRoot.createUniqueId() and
use the generated value to derive unique facelets ids. The new algorithm that
generate ids is very flexible and it will support this case. This base
[jira] [Commented] (MYFACES-3733) Implement vdl.createComponent(...)
[
https://issues.apache.org/jira/browse/MYFACES-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671618#comment-13671618
]
Leonardo Uribe commented on MYFACES-3733:
-
Committed first prototype. There are still things to do:
- Solve the refresh problem (allow c:if work in programmatic added sections).
- Review how cc:insertChildren works (ordering problem, take the solution for
mf-core 2.0.3 or earlier)
- (Optional) Reduce size of the listeners in session used.
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 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,
[jira] [Resolved] (MYFACES-3677) Implement 'javax.faces.WEBAPP_RESOURCES_DIRECTORY'
[ https://issues.apache.org/jira/browse/MYFACES-3677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3677. - Resolution: Fixed Fix Version/s: 2.2.0 Assignee: Leonardo Uribe Implement 'javax.faces.WEBAPP_RESOURCES_DIRECTORY' -- Key: MYFACES-3677 URL: https://issues.apache.org/jira/browse/MYFACES-3677 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: dennis hoersch Assignee: Leonardo Uribe Fix For: 2.2.0 Attachments: MYFACES-3677-patch.txt Implement 'javax.faces.WEBAPP_RESOURCES_DIRECTORY' as described in JSF 2.2 spec If this param is set, the runtime must interpret its value as a path, relative to the web app root, where resources are to be located. This param value must not start with a “/”, though it may contain “/” characters. If no such param exists, or its value is invalid, the value “resources”, without the quotes, must be used by the runtime as the value. I was looking last week for a way to move the 'resources' folder to a non-public location and read about this parameter. As I can't find if it is already implemented in 2.2 I gave it a try. I updated 'DefaultResourceHandlerSupport' to contain and use that parameter to instantiate the 'ExternalContextResourceLoader'. -- 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-3731) HTMLEncoder.encodeURIAtributte re-escapes already percent-encoded string
[ https://issues.apache.org/jira/browse/MYFACES-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3731. - Resolution: Fixed Fix Version/s: 2.1.12 2.0.18 Assignee: Leonardo Uribe HTMLEncoder.encodeURIAtributte re-escapes already percent-encoded string Key: MYFACES-3731 URL: https://issues.apache.org/jira/browse/MYFACES-3731 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.11 Reporter: dennis hoersch Assignee: Leonardo Uribe Fix For: 2.0.18, 2.1.12 In HTMLEncoder.encodeURIAtributte is a check to not re-escape already percent-encoded parts. But that code assumes the percent-encoded symbols to be uppercase letters. So in the following link the '%2b' is escaped to '%252b': Original: http://host/app/?ae=Itema=Opent=IPM.Noteid=RgB4E8INIm43RZNuTeFByn9IBwCfBp1RvH2jT7X5YNYS8KZjpBU%2bAABNyiydsdzWRbj76MCJ9qhxmaj0AAAJexvsurl=1;; Encoded: http://host/app/?ae=Itemamp;a=Openamp;t=IPM.Noteamp;id=RgB4E8INIm43RZNuTeFByn9IBwCfBp1RvH2jT7X5YNYS8KZjpBU%252bAABNyiydsdzWRbj76MCJ9qhxmaj0AAAJamp;exvsurl=1 (http://tools.ietf.org/html/rfc3986#page-12 says uppercase and lowercase letters have to be considered as equal.) -- 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-3716) Implement h:inputFile
[ https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13668926#comment-13668926 ] Leonardo Uribe commented on MYFACES-3716: - To generate all config files, myfaces-builder-plugin is used. Check for @JSFRenderer and other @JSFxxx annotations in myfaces code to see how it works. About change the api pom to include servlet 3.0, yes, it is ok to change it. In theory we should remain compatible with the lowest posible version of a library, but for JSF 2.2 there is no choice and we should set the dependency to 3.0 Implement h:inputFile - Key: MYFACES-3716 URL: https://issues.apache.org/jira/browse/MYFACES-3716 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Attachments: inputfile.patch Implement h:inputFile as described in the spec -- 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-3726) root context induces wrong urls
[
https://issues.apache.org/jira/browse/MYFACES-3726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13668085#comment-13668085
]
Leonardo Uribe commented on MYFACES-3726:
-
I can see the justification behind this. It is an special case and it should be
fixed at every location where the contextPath is used. I tried a simple jsf
application running as root and I can't see any difference, but that does not
means the fix is not valid, maybe here a combination of factors that at the end
cause the problem.
I have attached a patch with the changes to be commited. Thanks for report it.
root context induces wrong urls
---
Key: MYFACES-3726
URL: https://issues.apache.org/jira/browse/MYFACES-3726
Project: MyFaces Core
Issue Type: Bug
Reporter: Romain Manni-Bucau
When the webapp context is root (/) its name is still appended before the
urls (i didn't check all cases) so we end up with urls like //index.xhtml
which makes the navigation not working anymore.
I'm sure it happens at least in
org.apache.myfaces.shared.application.DefaultViewHandlerSupport#calculateActionURL
where
builder.append(contextPath);
should be replaced by
if (!/.equals(contextPath)) {
builder.append(contextPath);
}
We saw this issue in tomee (here a sample to reproduce it
https://github.com/maxtorzito/tomee-codi)
--
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-3726) root context induces wrong urls
[
https://issues.apache.org/jira/browse/MYFACES-3726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3726.
-
Resolution: Fixed
Fix Version/s: 2.1.12
2.0.18
Assignee: Leonardo Uribe
root context induces wrong urls
---
Key: MYFACES-3726
URL: https://issues.apache.org/jira/browse/MYFACES-3726
Project: MyFaces Core
Issue Type: Bug
Reporter: Romain Manni-Bucau
Assignee: Leonardo Uribe
Fix For: 2.0.18, 2.1.12
When the webapp context is root (/) its name is still appended before the
urls (i didn't check all cases) so we end up with urls like //index.xhtml
which makes the navigation not working anymore.
I'm sure it happens at least in
org.apache.myfaces.shared.application.DefaultViewHandlerSupport#calculateActionURL
where
builder.append(contextPath);
should be replaced by
if (!/.equals(contextPath)) {
builder.append(contextPath);
}
We saw this issue in tomee (here a sample to reproduce it
https://github.com/maxtorzito/tomee-codi)
--
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] (MYFACES-3729) Implement resource library contracts specification
Leonardo Uribe created MYFACES-3729: --- Summary: Implement resource library contracts specification Key: MYFACES-3729 URL: https://issues.apache.org/jira/browse/MYFACES-3729 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Implement resource library contracts specification is one of the main topics part of JSF 2.2 It is necessary to change all ResourceHandler default implementation to introduce the contracts on top or everything. Additionally, facelets algorithm must be updated to use createViewResource(...), but it is good to remember that it is resposibility of the vdl to decide if it uses it or not. -- 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-3729) Implement resource library contracts specification
[ https://issues.apache.org/jira/browse/MYFACES-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13665928#comment-13665928 ] Leonardo Uribe commented on MYFACES-3729: - Prototype committed. Simple tests done. Pending full test. Implement resource library contracts specification -- Key: MYFACES-3729 URL: https://issues.apache.org/jira/browse/MYFACES-3729 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Implement resource library contracts specification is one of the main topics part of JSF 2.2 It is necessary to change all ResourceHandler default implementation to introduce the contracts on top or everything. Additionally, facelets algorithm must be updated to use createViewResource(...), but it is good to remember that it is resposibility of the vdl to decide if it uses it or not. -- 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] (MYFACES-3730) Implement ViewDeclarationLanguageWrapper
Leonardo Uribe created MYFACES-3730: --- Summary: Implement ViewDeclarationLanguageWrapper Key: MYFACES-3730 URL: https://issues.apache.org/jira/browse/MYFACES-3730 Project: MyFaces Core Issue Type: Task Reporter: Leonardo Uribe Implement ViewDeclarationLanguageWrapper -- 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-3730) Implement ViewDeclarationLanguageWrapper
[ https://issues.apache.org/jira/browse/MYFACES-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3730. - Resolution: Fixed Fix Version/s: 2.2.0 Assignee: Leonardo Uribe Implement ViewDeclarationLanguageWrapper Key: MYFACES-3730 URL: https://issues.apache.org/jira/browse/MYFACES-3730 Project: MyFaces Core Issue Type: Task Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.2.0 Implement ViewDeclarationLanguageWrapper -- 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-3727) ConversationManager.hasConversationContext buggy
[
https://issues.apache.org/jira/browse/MYFACES-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13664152#comment-13664152
]
Leonardo Uribe commented on MYFACES-3727:
-
This does not seems to be a MyFaces Core bug. ConversationManager class does
not exists. Check first which package belongs the class.
ConversationManager.hasConversationContext buggy
Key: MYFACES-3727
URL: https://issues.apache.org/jira/browse/MYFACES-3727
Project: MyFaces Core
Issue Type: Bug
Components: General
Reporter: Jarek
The method says:
hasConversationContext() {
return getCurrentConversationContext() == null;
}
should rather be the opposite -
!= null
...
--
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-3720) [restoreView/restoreState] java.lang.ClassCastException: java.util.HashMap cannot be cast to javax.faces.convert.Converter
[
https://issues.apache.org/jira/browse/MYFACES-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13656148#comment-13656148
]
Leonardo Uribe commented on MYFACES-3720:
-
I have checked the problem in deep and my opinion is the problem is not in the
converter (you should not worry about how converter instances are instantiated.
It does not matter if is a singleton or if it is created multiple times, the
impact in performance is minimal). Instead, the stack trace shows in some place
inside the code there is a desynchronization between the state and the way
facelets algorithm is generated.
The algorithm in myfaces is ok, both the one that handles the state and the one
that generated unique ids in facelets.
With the information provided I was able to track down the issue to these lines
in pf_ViewAll.xhtml
p:tab title=Payment/Status
ui:include src=/orders/pf_ViewPaymentStatus.xhtml/
/p:tab
p:tab title=Other
ui:include src=/orders/pf_ViewOther.xhtml/
/p:tab
p:tab title=Attractions
The id for Other link in p:tab is ordersViewForm:orderViewTabView:j_id_b_1_4g
and the id for Attractions link is ordersViewForm:orderViewTabView:j_id_b_1_4t
Since the problematic component is at
ordersViewForm:orderViewTabView:j_id_b_1_4q_1 , I suppose there is something
inside
/orders/pf_ViewOther.xhtml
That is causing the problem. Since the id generation start a new _, you
should take a look at the first occurrence of c:if , ui:include src=#{...},
c:choose or c:forEach. Probably an use of c:forEach / tag could cause the
problem, because it is the only tag that can desynchronize the state (c:forEach
has some issues that cause a lot of trouble as described in issues like).
My suggestion is avoid all use of c:forEach tag. See MYFACES-3570 and
MYFACES-3389 for details. You can also try to comment the code inside that
facelet to see what's the code that is causing trouble.
Please check /orders/pf_ViewOther.xhtml or let us know what's inside this
facelet tag.
For now I'm sure it is not a myfaces issue, but I'll keep this issue open until
we can find what's going on.
[restoreView/restoreState] java.lang.ClassCastException: java.util.HashMap
cannot be cast to javax.faces.convert.Converter
--
Key: MYFACES-3720
URL: https://issues.apache.org/jira/browse/MYFACES-3720
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.10, 2.1.11
Environment: 1. TomEE 1.6.0 snapshot (2013-04-29) which includes
MyFaces 2.1.11
2. PrimeFaces 3.5 and PrimeFaces 4.0 snapshot
Reporter: Howard W. Smith, Jr.
Original Estimate: 28h
Remaining Estimate: 28h
Originally reported as OmniFaces issue # 167 (please take a look at this, as
I attached some files there in OmniFaces issue tracker)
https://code.google.com/p/omnifaces/issues/detail?id=167
OmniFaces response was the following:
Project Member #3 balusc
This problem is indeed not related to o:enableRestorableView. The only
occurrence in the stack trace is just the delegation to super (i.e. the
process continues less or more as if the o:enableRestorableView was never
involved):
UIViewRoot restoredView = super.restoreView(context, viewId);
Below is stack trace with TomEE 1.6.0 (2013-04-29), myFaces 2.1.11, and
PrimeFaces 4.0 snapshot. Is this a MyFaces bug or user error?
May 09, 2013 8:06:54 AM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [Faces Servlet] in context with path
[/mcmsweb] threw exception [Error restoring component:
ordersViewForm:orderViewTabView:j_id_b_1_4q_1] with root cause
java.lang.ClassCastException: java.util.HashMap cannot be cast to
javax.faces.convert.Converter
at javax.faces.component.UIOutput.restoreState(UIOutput.java:248)
at
org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:687)
at
org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:706)
at
org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:706)
at
org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:706)
at
org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:706)
at
[jira] [Commented] (MYFACES-3720) [restoreView/restoreState] java.lang.ClassCastException: java.util.HashMap cannot be cast to javax.faces.convert.Converter
[ https://issues.apache.org/jira/browse/MYFACES-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13656605#comment-13656605 ] Leonardo Uribe commented on MYFACES-3720: - Thanks Howard for let us know what's inside pf_ViewOther.xhtml . It is good to know that the exception does not occur in typical situations. It is clear the stacktrace shows the exception occur in a postback, when the view is being restored. The evidence suggest there is no duplicate id exception too. The HashMap is not related to p:dataTable. To put it in simple words, the exception suggest a state is being saved under the key ordersViewForm:orderViewTabView:j_id_b_1_4q_1, but when it is restored the state does not match with the current component holding the key as clientId. That's very unlikely, because the algorithm was designed to produce stable client ids, and has been widely tested. But it can be possible to get an exception like that in development time. Press F5 send the last command to the page, in this case a POST with a valid viewState token. But let's suppose a change happen on the page between the last request and the new one. The result is have a valid POST, the viewState pass the check but when it is restored, the state is obviously not synchronized with the facelet page and the exception is thrown. You see the exception, but later when you try something else it just disappear, because the invalid data is gone. In production environment this will never happen, because in that case .xhtml files does not change (no refresh period and no updates on the pages). Since it only occur under very special situations, I wouldn't worry about that exception, because it is not a real bug. It is not possible to do anything from MyFaces side to deal with this, and it does not suppose a problem in production environment. [restoreView/restoreState] java.lang.ClassCastException: java.util.HashMap cannot be cast to javax.faces.convert.Converter -- Key: MYFACES-3720 URL: https://issues.apache.org/jira/browse/MYFACES-3720 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.10, 2.1.11 Environment: 1. TomEE 1.6.0 snapshot (2013-04-29) which includes MyFaces 2.1.11 2. PrimeFaces 3.5 and PrimeFaces 4.0 snapshot Reporter: Howard W. Smith, Jr. Original Estimate: 28h Remaining Estimate: 28h Originally reported as OmniFaces issue # 167 (please take a look at this, as I attached some files there in OmniFaces issue tracker) https://code.google.com/p/omnifaces/issues/detail?id=167 OmniFaces response was the following: Project Member #3 balusc This problem is indeed not related to o:enableRestorableView. The only occurrence in the stack trace is just the delegation to super (i.e. the process continues less or more as if the o:enableRestorableView was never involved): UIViewRoot restoredView = super.restoreView(context, viewId); Below is stack trace with TomEE 1.6.0 (2013-04-29), myFaces 2.1.11, and PrimeFaces 4.0 snapshot. Is this a MyFaces bug or user error? May 09, 2013 8:06:54 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [Faces Servlet] in context with path [/mcmsweb] threw exception [Error restoring component: ordersViewForm:orderViewTabView:j_id_b_1_4q_1] with root cause java.lang.ClassCastException: java.util.HashMap cannot be cast to javax.faces.convert.Converter at javax.faces.component.UIOutput.restoreState(UIOutput.java:248) at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:687) at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:706) at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:706) at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:706) at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:706) at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:706) at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:706) at
[jira] [Created] (MYFACES-3721) Override of uniqueIdCounter for UIViewRoot in restoreView cause component duplicate id exception
Leonardo Uribe created MYFACES-3721: --- Summary: Override of uniqueIdCounter for UIViewRoot in restoreView cause component duplicate id exception Key: MYFACES-3721 URL: https://issues.apache.org/jira/browse/MYFACES-3721 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe I have found an issue with the solution applied in MYFACES-3663. The steps to cause the problem are the following: 1. The view is rendered and some unique ids are generated. UIViewRoot has state and it is saved. 2. The view needs to be restored, PSS algorithm takes the uniqueIdCounter from the state and set it to UIViewRoot, then the initial state is constructed using facelets algorithm 3. Inside facelets algorithm, a new component is created and that increase uniqueIdCounter (f:ajax tag handler adds default jsf.js and ask for a unique id from UIViewRoot). 4. The delta state is applied, overriding uniqueIdCounter. 5. A new component is created in render response phase, creating the duplicate id condition. 6. The state saving algorithm detects the duplicate id and throw duplicate id exception. The conditions required to reproduce the problem are very unlikely, so other tests done were not able to reproduce the problem. -- 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-3721) Override of uniqueIdCounter for UIViewRoot in restoreView cause component duplicate id exception
[ https://issues.apache.org/jira/browse/MYFACES-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3721. - Resolution: Fixed Fix Version/s: 2.1.12 2.0.18 Override of uniqueIdCounter for UIViewRoot in restoreView cause component duplicate id exception Key: MYFACES-3721 URL: https://issues.apache.org/jira/browse/MYFACES-3721 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.18, 2.1.12 I have found an issue with the solution applied in MYFACES-3663. The steps to cause the problem are the following: 1. The view is rendered and some unique ids are generated. UIViewRoot has state and it is saved. 2. The view needs to be restored, PSS algorithm takes the uniqueIdCounter from the state and set it to UIViewRoot, then the initial state is constructed using facelets algorithm 3. Inside facelets algorithm, a new component is created and that increase uniqueIdCounter (f:ajax tag handler adds default jsf.js and ask for a unique id from UIViewRoot). 4. The delta state is applied, overriding uniqueIdCounter. 5. A new component is created in render response phase, creating the duplicate id condition. 6. The state saving algorithm detects the duplicate id and throw duplicate id exception. The conditions required to reproduce the problem are very unlikely, so other tests done were not able to reproduce the problem. -- 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] [Deleted] (MFHTML5-19) murilo moveis planejados
[ https://issues.apache.org/jira/browse/MFHTML5-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe deleted MFHTML5-19: -- murilo moveis planejados Key: MFHTML5-19 URL: https://issues.apache.org/jira/browse/MFHTML5-19 Project: MyFaces HTML5 Component Library Issue Type: Test Environment: www.spacoshow.com Reporter: murilo mendonça Assignee: Ali Ok Original Estimate: 612h Remaining Estimate: 612h moveis de marcenaria -- 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-1892) validator element in faces-config should support nested attribute and property definitions
[ https://issues.apache.org/jira/browse/MYFACES-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13647147#comment-13647147 ] Leonardo Uribe commented on MYFACES-1892: - I know it could be a good idea to do it, but if the reference implementation (in this case mojarra) does not provide the feature, it is probably because that was not the idea. In that case, the best thing to do is ask to the expert group first, filling an issue in: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC and just put a reference to this issue to remind where it came from. validator element in faces-config should support nested attribute and property definitions -- Key: MYFACES-1892 URL: https://issues.apache.org/jira/browse/MYFACES-1892 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.3 Reporter: Simon Kitching Attachments: MYFACES-1892.patch As shown in this dtd: http://java.sun.com/dtd/web-facesconfig_1_1.dtd the validator element in a faces-config.xml file should support nested attribute and property elements: validator validator-idxyValidtor/validator-name validator-classcom.xy.XyValidator/validator-class property property-namelength/property-name property-classjava.lang.Integer/property default-value40/default-value /property /validator However this appears to never have been implemented in either 1.1.x or 1.2.x of core; only validator-id and validator-class are supported. Note that the equivalent feature exists for converters, and does appear to have been implemented. See the digester rules registered in the constructor for class org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl Reported by Joerg (superjoerch at gmx.de) on the myfaces user list, -- 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] (MYFACES-3716) Implement h:fileUpload
Leonardo Uribe created MYFACES-3716: --- Summary: Implement h:fileUpload Key: MYFACES-3716 URL: https://issues.apache.org/jira/browse/MYFACES-3716 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Implement h:fileUpload as described in the spec -- 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] (MYFACES-3717) Implement role attribute in related components and renderers
Leonardo Uribe created MYFACES-3717: --- Summary: Implement role attribute in related components and renderers Key: MYFACES-3717 URL: https://issues.apache.org/jira/browse/MYFACES-3717 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe -- 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] (MYFACES-3718) Replace http://java.sun.com/jsf with http://xmlns.jcp.org/jsf
Leonardo Uribe created MYFACES-3718: --- Summary: Replace http://java.sun.com/jsf with http://xmlns.jcp.org/jsf Key: MYFACES-3718 URL: https://issues.apache.org/jira/browse/MYFACES-3718 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe According to the spec the new namespace should be http://xmlns.jcp.org/jsf , but http://java.sun.com/jsf should still work. This include all libraries that has that prefix, including jstl tags too. -- 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-3718) Replace http://java.sun.com/jsf with http://xmlns.jcp.org/jsf
[ https://issues.apache.org/jira/browse/MYFACES-3718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3718. - Resolution: Fixed Fix Version/s: 2.2.0 Assignee: Leonardo Uribe Replace http://java.sun.com/jsf with http://xmlns.jcp.org/jsf - Key: MYFACES-3718 URL: https://issues.apache.org/jira/browse/MYFACES-3718 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.2.0 According to the spec the new namespace should be http://xmlns.jcp.org/jsf , but http://java.sun.com/jsf should still work. This include all libraries that has that prefix, including jstl tags too. -- 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-1892) validator element in faces-config should support nested attribute and property definitions
[ https://issues.apache.org/jira/browse/MYFACES-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13641285#comment-13641285 ] Leonardo Uribe commented on MYFACES-1892: - Does this work with Mojarra? We need to know first if the reference implementation has this behavior, before commit it inside myfaces code. validator element in faces-config should support nested attribute and property definitions -- Key: MYFACES-1892 URL: https://issues.apache.org/jira/browse/MYFACES-1892 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.3 Reporter: Simon Kitching Attachments: MYFACES-1892-New.patch As shown in this dtd: http://java.sun.com/dtd/web-facesconfig_1_1.dtd the validator element in a faces-config.xml file should support nested attribute and property elements: validator validator-idxyValidtor/validator-name validator-classcom.xy.XyValidator/validator-class property property-namelength/property-name property-classjava.lang.Integer/property default-value40/default-value /property /validator However this appears to never have been implemented in either 1.1.x or 1.2.x of core; only validator-id and validator-class are supported. Note that the equivalent feature exists for converters, and does appear to have been implemented. See the digester rules registered in the constructor for class org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl Reported by Joerg (superjoerch at gmx.de) on the myfaces user list, -- 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] (MYFACES-3714) Implement stateless mode using f:view transient attribute
Leonardo Uribe created MYFACES-3714: --- Summary: Implement stateless mode using f:view transient attribute Key: MYFACES-3714 URL: https://issues.apache.org/jira/browse/MYFACES-3714 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Implement stateless mode using f:view transient attribute The big problem with this stuff is what happen when view protection is considered and the resulting relationship between the state mode used (client or server) and mixing everything together. For example, view protection relies on what's inside javax.faces.ViewState hidden field and how it is encoded. Theorically javax.faces.ViewState protects against CSRF attacks, but with a special stateless token it could be possible to use that token into non stateless views. We should prevent that adding proper checks into the StateManagementStrategy and the Restore View phase. In theory, it is necessary to extend org.apache.myfaces.application.StateCache abstract class to reflect the necessary logic to ensure protected views are always secured, even if they are declared as stateless. -- 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] (MYFACES-3715) Remove unnecessary parameters or features from earlier versions in MyFaces 2.2
Leonardo Uribe created MYFACES-3715: --- Summary: Remove unnecessary parameters or features from earlier versions in MyFaces 2.2 Key: MYFACES-3715 URL: https://issues.apache.org/jira/browse/MYFACES-3715 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Priority: Blocker Before any release, it is necessary to remove unnecessary parameters or features from earlier versions One example is org.apache.myfaces.HANDLE_STATE_CACHING_MECHANICS web config param. It was added in 2.0.x/2.1.x to deal with StateManager implementations that relies on previous behavior, but in 2.2.x, we should unify that part (ri behavior). Other example is org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE web config param. With the standard javascript api (jsf.js), this behavior was included in the javascript file by default. The param was included only for backward compatibility with previous versions (JSF 1.2). There are other examples of config params like org.apache.myfaces.PRETTY_HTML that are only things left from 1.1.x versions. It is necessary to do this part before any official release. -- 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] (MYFACES-3712) [perf] UILeaf.setId() does not require the valid id check, because it is always generated by facelets
Leonardo Uribe created MYFACES-3712: --- Summary: [perf] UILeaf.setId() does not require the valid id check, because it is always generated by facelets Key: MYFACES-3712 URL: https://issues.apache.org/jira/browse/MYFACES-3712 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe UILeaf.setId() does not require the valid id check, because it is always generated by facelets. There is no reason to do that check over an over each time setId() is called in that location, because UILeaf is a wrapper for html markup, which only needs to be rendered and does not have any special behavior in decoding or validation. -- 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-3712) [perf] UILeaf.setId() does not require the valid id check, because it is always generated by facelets
[ https://issues.apache.org/jira/browse/MYFACES-3712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3712. - Resolution: Fixed Fix Version/s: 2.1.12 2.0.18 [perf] UILeaf.setId() does not require the valid id check, because it is always generated by facelets - Key: MYFACES-3712 URL: https://issues.apache.org/jira/browse/MYFACES-3712 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.18, 2.1.12 UILeaf.setId() does not require the valid id check, because it is always generated by facelets. There is no reason to do that check over an over each time setId() is called in that location, because UILeaf is a wrapper for html markup, which only needs to be rendered and does not have any special behavior in decoding or validation. -- 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-3711) Add alwaysRecompile mode for EL Expression Cache Mode
[
https://issues.apache.org/jira/browse/MYFACES-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3711.
-
Resolution: Fixed
Fix Version/s: 2.1.12
Add alwaysRecompile mode for EL Expression Cache Mode
-
Key: MYFACES-3711
URL: https://issues.apache.org/jira/browse/MYFACES-3711
Project: MyFaces Core
Issue Type: New Feature
Components: JSR-314
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Fix For: 2.1.12
Attachments: MYFACES-3711-1-alwaysRecompile.patch
In MYFACES-3160, EL Expression Cache Mode was introduced but soon it was seen
a
problem found on MYFACES-3169 (ui:param and c:set implementations does not
work as expected).
There are two problems that limit the scope where EL Expression Cache can
be used:
1. Facelets user tags cannot cache EL Expressions.
2. Inclusions using ui:param must always contains the same number of
parameters.
To understand the reasons it is worth to remember this example:
a.xhtml
ui:composition template=c.xhtml
ui:param name=var1 value=value1/
/ui:composition
b.xhtml
ui:composition template=c.xhtml
ui:param name=var1 value=value1/
ui:param name=var2 value=value2/
/ui:composition
c.xhtml
ui:composition
h:outputText value=#{var1}/
h:outputText value=#{var2}/
/ui:composition
When facelet c.xhtml is constructed from a.xhtml, var2 is not recognized as
a parameter so all EL expressions inside c.xhtml holding refereces to var2
will be cached. Later, facelet c.xhtml is reused from b.xhtml but since
some EL expressions are cached the passed value in var2 is not taken into
account and the error arise.
In this point it is good to remember that ui:include or ui:decorate or user
tags are build view time tags, so they are executed only when the view is
built. Parameters or attributes passed by ui:param or as user tag attributes
follows the same principle, they are calculated on build view time through
VariableMapper and the evaluation is stored inside the EL Expression. This
means all EL Expressions holding references to these variables cannot be
cached and needs to be generated each time the view is built.
There is no way to know beforehand which references are affected, because
in a template or an user tag there is no declaration of the parameters or
attributes. But from user point of view that's good, because in this context
a declaration of the parameters is just not necessary.
The problem is ui:param and user tags are very useful features, widely used.
A solution to this problem will improve performance in those cases.
I have been thinking for a long time how to solve this, trying different
strategies. Use some kind of concurrency algorithm inside TagAttributeImpl
does not work because it is too expensive, or use a central storage for
cache the expressions by the cost involved in the comparisons.
The objective of cache EL expressions inside facelets abstract syntax tree
(AST) is minimize the calculations required to get a valid expression. EL
implementations has already an internal map that cache that information,
but that code usually has synchronized blocks or similar things. In that
sense, the idea is rely on that storage in those EL expressions where
there is no choice and they need to be recreated.
After doing many experiments in this part, I came up with a solution, which
involves the following points:
1. Associate to a facelet, the parameters that were considered as passed
through ui:param or as a user tag attribute. If in some point of time
we know for example c.xhtml uses var1, just consider it as c.xhtml(var1).
2. Use DefaultVariableMapper to track the parameters that are passed through
ui:param or as a user tag attribute. When the EL expression is created, if
it uses at least one parameter, mark the expression as not cacheable.
3. Override FaceletCache implementation and force a recompilation of a
facelet if a new parameter is detected that was not considered the first
time the template was created.
4. A facelet stored in the cache can be used if and only if all the
parameters used for the template where considered when it was compiled at
first time.
In the example proposed, when facelet c.xhtml is constructed from a.xhtml,
we say that c.xhtml was built with var1 as a known parameter, or
c.xhtml(var1). when we try to reuse facelet c.xhtml from b.xhtml, we discover
that var2 is also a parameter, but since the cached facelet is c.xhtml(var1),
the algorithm discard the facelet and create a new one, but taking into
account var2 too, so the new facelet becomes c.xhtml(var1,var2). If there
is a call to c.xhtml with no params, it is considered that c.xhtml(var1,var2)
can be used in that case.
[jira] [Resolved] (MYFACES-3705) Concurrency feature in FaceletCacheImpl
[
https://issues.apache.org/jira/browse/MYFACES-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3705.
-
Resolution: Fixed
Fix Version/s: 2.1.12
Concurrency feature in FaceletCacheImpl
-
Key: MYFACES-3705
URL: https://issues.apache.org/jira/browse/MYFACES-3705
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.0
Environment: All
Reporter: Pasi Salminen
Assignee: Leonardo Uribe
Priority: Trivial
Fix For: 2.1.12
Original Estimate: 1h
Remaining Estimate: 1h
I'm implementing my own FaceletCache which is decorating
org.apache.myfaces.view.facelets.impl.FaceletCacheImpl by adding my own
caching policy. When I was studying the code I'm decorating, I noticed that
scrictly speaking it was not behaving. The problem lies in this code snippet
(and the same for metadata facelets):
if (_refreshPeriod != NO_CACHE_DELAY)
{
MapString, DefaultFacelet newLoc = new HashMapString,
DefaultFacelet(_facelets);
newLoc.put(key, f);
_facelets = newLoc;
}
First of all, multiple concurrent modifications of _facelets map may cause
lost updates. Think what happens when thread one copies the hashmap, updates
local copy but before it sets the reference, thread b does the same. One
update is now lost. In reality, the number of concurrent threads and number
of lost updates may be much larger. The second thing is that the new
reference set to _facelets is not quaranteed to be visible to other threads
due to missing synchronization. To prove my concerns, I created a small test
bench which proved my doubts and was able to show both lost updates and
visibility problem. When I modified the map to be ConcurrentHashMap and just
used put-method all problems vanished. So instead of
MapString, DefaultFacelet newLoc = new HashMapString,
DefaultFacelet(_facelets);
newLoc.put(key, f);
_facelets = newLoc;
I used
_facelets.put( key,f );
I know it may not be a problem, possibly just causing multiple loads of same
resource, but still I don't feel comfortable with the code behaving
concurrency-wise incorrectly.
BR, Paci
--
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-3683) Implement AjaxBehavior resetValues and delay
[ https://issues.apache.org/jira/browse/MYFACES-3683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13638483#comment-13638483 ] Leonardo Uribe commented on MYFACES-3683: - I checked the provided patches and commit the parts that are pending (some parts were already in place and the other part requires some fixes). Still pending resetValues stuff on server side. Implement AjaxBehavior resetValues and delay Key: MYFACES-3683 URL: https://issues.apache.org/jira/browse/MYFACES-3683 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Attachments: MYFACES-3683-delay1.patch, MYFACES-3683-delay2.patch, MYFACES-3683-delay3.patch Implement AjaxBehavior resetValues and delay as described in the spec. -- 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-3538) Boguous implementation of the HTTP OPTIONS method
[ https://issues.apache.org/jira/browse/MYFACES-3538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13638528#comment-13638528 ] Leonardo Uribe commented on MYFACES-3538: - The spec specifies in a explicit way the override of service() method. In JSF 2.2 it was added the following clarification (see FacesServlet javadoc): ... Allowable HTTP Methods The JSF specification only requires the use of the GET and POST http methods. If your web application does not require any other http methods, such as PUT and DELETE, please consider restricting the allowable http methods using the http-method and http-method-omission elements. Please see the Security of the Java Servlet Specification for more information the use of these elements. ... I understand the justification for the change proposed, but we cannot change that part in that way without break the spec. Instead, the idea could be introduce a myfaces specific web config parameter to restrict the valid methods. In Mojarra case there is a param called com.sun.faces.allowedHttpMethods , maybe we can do something similar. Boguous implementation of the HTTP OPTIONS method - Key: MYFACES-3538 URL: https://issues.apache.org/jira/browse/MYFACES-3538 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.1.7 Reporter: Mark Struberg Attachments: JIRA-MYFACES-3538.patch My colleague Christoph Ledl found the following issue in MyFaces: Wrong implementation of the OPTIONS method FacesServlet does not handle OPTIONS (and possilby other methods) correctly. It looks like these request are processed like a GET, which is wrong. the implementation of FacesServlet.service() does not deal with methods. one cheap fix would be to send 405 (SC_METHOD_NOT_ALLOWED) for all unsupported methods like TRACE and OPTIONS. another approach would to extend HttpServlet (instead of implementing Servlet) and implement only required methods like GET and POST (this would leave the other methods to the default implementation) citeation of HttpServlet java doc: There's almost no reason to override the service method. Likewise, there's almost no reason to override the doOptions and doTrace methods. --- This materializes in the following Exception: Feb 28 17:48:13 j04 [http-8080-exec-14] ERROR log.LogFilter j04 0 43396625FA6E47DF1C03B12B60BF request done OPTIONS /events/ical.xhtml?locale=detoken=488d-1-b7da-f29fcf074 time=749.16ms cpu=610ms ex=IllegalStateException msg=null UA=Microsoft-WebDAV-MiniRedir/6.1.7601 Feb 28 17:48:13 j04 [http-8080-exec-14] INFO log.LogFilter params: token=48b0368d-b7da-f2974 locale=de Feb 28 17:48:13 j04 [http-8080-exec-14] ERROR [/events].[Faces Servlet] Servlet.service() for servlet Faces Servlet threw exception Feb 28 17:48:13 j04 java.lang.IllegalStateException Feb 28 17:48:13 j04 at org.apache.catalina.connector.ResponseFacade.sendRedirect(ResponseFacade.java:435) Feb 28 17:48:13 j04 at org.apache.myfaces.context.servlet.ServletExternalContextImpl.redirect(ServletExternalContextImpl.java:465) Feb 28 17:48:13 j04 at org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.DefaultWindowHandler.sendRedirect(DefaultWindowHandler.java:104) Feb 28 17:48:13 j04 at sun.reflect.GeneratedMethodAccessor1600.invoke(Unknown Source) Feb 28 17:48:13 j04 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Feb 28 17:48:13 j04 at java.lang.reflect.Method.invoke(Method.java:597) Feb 28 17:48:13 j04 at org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:329) Feb 28 17:48:13 j04 at org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:122) Most times this method gets used by mobile browsers in smartphones. -- 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-3710) Create SelectItemsIterator only once in UISelectOne.validateValue()
[
https://issues.apache.org/jira/browse/MYFACES-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3710.
-
Resolution: Fixed
Fix Version/s: 2.1.12
2.0.18
Assignee: Leonardo Uribe
_SelectItemsIterator usually involves evaluate EL expressions and that can be
slow. The array is inexpensive compared to that, so it has sense to use it also
in UISelectOne.
Thanks to Dennis Hoersch for provide this patch.
Create SelectItemsIterator only once in UISelectOne.validateValue()
---
Key: MYFACES-3710
URL: https://issues.apache.org/jira/browse/MYFACES-3710
Project: MyFaces Core
Issue Type: Improvement
Affects Versions: 2.1.11
Reporter: dennis hoersch
Assignee: Leonardo Uribe
Fix For: 2.0.18, 2.1.12
Creating the SelectItemsIterator seams to be a bit slow when using a big
collection. (At least using the Tomahawk UISlectItems and transforming a list
of Objects to SelectItems with evaluating expressions on each item.)
UISelectMany stores the Iterator in a local collection to use that twice. I
think the same could be done in UISelectOne:
CollectionSelectItem items = new ArrayListSelectItem();
for (IteratorSelectItem iter = new _SelectItemsIterator(this,
context); iter.hasNext();)
{
items.add(iter.next());
}
// selected value must match to one of the available options
// and if required is true it must not match an option with
noSelectionOption set to true (since 2.0)
Converter converter = getConverter();
if (_SelectItemsUtil.matchValue(context, this, value, items.iterator(),
converter))
{
if (! this.isRequired())
{
return; // Matched Required false, so return ok.
}
if (! _SelectItemsUtil.isNoSelectionOption(context, this, value,
items.iterator(), converter))
{
return; // Matched Required true No-selection did NOT
match, so return ok.
}
}
--
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-3707) org.apache.myfaces.STANDARD_JSF_AJAX_LIBRARY_LOADED
[ https://issues.apache.org/jira/browse/MYFACES-3707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13638582#comment-13638582 ] Leonardo Uribe commented on MYFACES-3707: - I think for your particular case, a custom phase listener that set this param to true will work better. org.apache.myfaces.STANDARD_JSF_AJAX_LIBRARY_LOADED --- Key: MYFACES-3707 URL: https://issues.apache.org/jira/browse/MYFACES-3707 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.0.16, 2.0.17 Reporter: Juanjo Alvarez Priority: Minor I think could be good in portal environment to have a new context parameter like org.apache.myfaces.STANDARD_JSF_AJAX_LIBRARY_LOADED in a way that true would prevent AjaxHandler to add outputScript component to the head section(skip call registerJsfAjaxDefaultResource). In this case, developer would be responsible for including the resource -- 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] (MYFACES-3713) [perf] use getFacetCount() when possible and avoid create iterator instances
Leonardo Uribe created MYFACES-3713: --- Summary: [perf] use getFacetCount() when possible and avoid create iterator instances Key: MYFACES-3713 URL: https://issues.apache.org/jira/browse/MYFACES-3713 Project: MyFaces Core Issue Type: Improvement Reporter: Leonardo Uribe Priority: Trivial There are some spots where getFacets() is called directly or getFacets().isEmpty is used. The ideal is prevent that call and use getFacetCount() when possible. Also, use getFacetsAndChildren() is nicer but use getFacetCount() prevents create 1 iterator per component class that does not have facets attached, which is a common case. The effect is very, very small, but anyway it is quite simple to do it. -- 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-3713) [perf] use getFacetCount() when possible and avoid create iterator instances
[ https://issues.apache.org/jira/browse/MYFACES-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3713. - Resolution: Fixed Fix Version/s: 2.1.12 2.0.18 Assignee: Leonardo Uribe [perf] use getFacetCount() when possible and avoid create iterator instances Key: MYFACES-3713 URL: https://issues.apache.org/jira/browse/MYFACES-3713 Project: MyFaces Core Issue Type: Improvement Reporter: Leonardo Uribe Assignee: Leonardo Uribe Priority: Trivial Fix For: 2.0.18, 2.1.12 There are some spots where getFacets() is called directly or getFacets().isEmpty is used. The ideal is prevent that call and use getFacetCount() when possible. Also, use getFacetsAndChildren() is nicer but use getFacetCount() prevents create 1 iterator per component class that does not have facets attached, which is a common case. The effect is very, very small, but anyway it is quite simple to do it. -- 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] (MYFACES-3711) Add alwaysRecompile mode for EL Expression Cache Mode
Leonardo Uribe created MYFACES-3711:
---
Summary: Add alwaysRecompile mode for EL Expression Cache Mode
Key: MYFACES-3711
URL: https://issues.apache.org/jira/browse/MYFACES-3711
Project: MyFaces Core
Issue Type: New Feature
Components: JSR-314
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
In MYFACES-3160, EL Expression Cache Mode was introduced but soon it was seen a
problem found on MYFACES-3169 (ui:param and c:set implementations does not
work as expected).
There are two problems that limit the scope where EL Expression Cache can
be used:
1. Facelets user tags cannot cache EL Expressions.
2. Inclusions using ui:param must always contains the same number of
parameters.
To understand the reasons it is worth to remember this example:
a.xhtml
ui:composition template=c.xhtml
ui:param name=var1 value=value1/
/ui:composition
b.xhtml
ui:composition template=c.xhtml
ui:param name=var1 value=value1/
ui:param name=var2 value=value2/
/ui:composition
c.xhtml
ui:composition
h:outputText value=#{var1}/
h:outputText value=#{var2}/
/ui:composition
When facelet c.xhtml is constructed from a.xhtml, var2 is not recognized as
a parameter so all EL expressions inside c.xhtml holding refereces to var2
will be cached. Later, facelet c.xhtml is reused from b.xhtml but since
some EL expressions are cached the passed value in var2 is not taken into
account and the error arise.
In this point it is good to remember that ui:include or ui:decorate or user
tags are build view time tags, so they are executed only when the view is
built. Parameters or attributes passed by ui:param or as user tag attributes
follows the same principle, they are calculated on build view time through
VariableMapper and the evaluation is stored inside the EL Expression. This
means all EL Expressions holding references to these variables cannot be
cached and needs to be generated each time the view is built.
There is no way to know beforehand which references are affected, because
in a template or an user tag there is no declaration of the parameters or
attributes. But from user point of view that's good, because in this context
a declaration of the parameters is just not necessary.
The problem is ui:param and user tags are very useful features, widely used.
A solution to this problem will improve performance in those cases.
I have been thinking for a long time how to solve this, trying different
strategies. Use some kind of concurrency algorithm inside TagAttributeImpl
does not work because it is too expensive, or use a central storage for
cache the expressions by the cost involved in the comparisons.
The objective of cache EL expressions inside facelets abstract syntax tree
(AST) is minimize the calculations required to get a valid expression. EL
implementations has already an internal map that cache that information,
but that code usually has synchronized blocks or similar things. In that
sense, the idea is rely on that storage in those EL expressions where
there is no choice and they need to be recreated.
After doing many experiments in this part, I came up with a solution, which
involves the following points:
1. Associate to a facelet, the parameters that were considered as passed
through ui:param or as a user tag attribute. If in some point of time
we know for example c.xhtml uses var1, just consider it as c.xhtml(var1).
2. Use DefaultVariableMapper to track the parameters that are passed through
ui:param or as a user tag attribute. When the EL expression is created, if
it uses at least one parameter, mark the expression as not cacheable.
3. Override FaceletCache implementation and force a recompilation of a
facelet if a new parameter is detected that was not considered the first
time the template was created.
4. A facelet stored in the cache can be used if and only if all the
parameters used for the template where considered when it was compiled at
first time.
In the example proposed, when facelet c.xhtml is constructed from a.xhtml,
we say that c.xhtml was built with var1 as a known parameter, or
c.xhtml(var1). when we try to reuse facelet c.xhtml from b.xhtml, we discover
that var2 is also a parameter, but since the cached facelet is c.xhtml(var1),
the algorithm discard the facelet and create a new one, but taking into
account var2 too, so the new facelet becomes c.xhtml(var1,var2). If there
is a call to c.xhtml with no params, it is considered that c.xhtml(var1,var2)
can be used in that case.
The final effect is just some extra compilations of the same facelet at
startup but in the medium/long term, the information we need is calculated
and associated with the facelet url. Nice!. Facelet is very fast doing those
extra compilation steps, and the final effect over performance really pays
off. We could even set this mode as default.
The only disadvantage
[jira] [Commented] (MYFACES-3711) Add alwaysRecompile mode for EL Expression Cache Mode
[
https://issues.apache.org/jira/browse/MYFACES-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13637290#comment-13637290
]
Leonardo Uribe commented on MYFACES-3711:
-
If no objections, I'll commit the proposed code soon (in 2.1.x and 2.2.x
branches)
Add alwaysRecompile mode for EL Expression Cache Mode
-
Key: MYFACES-3711
URL: https://issues.apache.org/jira/browse/MYFACES-3711
Project: MyFaces Core
Issue Type: New Feature
Components: JSR-314
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Attachments: MYFACES-3711-1-alwaysRecompile.patch
In MYFACES-3160, EL Expression Cache Mode was introduced but soon it was seen
a
problem found on MYFACES-3169 (ui:param and c:set implementations does not
work as expected).
There are two problems that limit the scope where EL Expression Cache can
be used:
1. Facelets user tags cannot cache EL Expressions.
2. Inclusions using ui:param must always contains the same number of
parameters.
To understand the reasons it is worth to remember this example:
a.xhtml
ui:composition template=c.xhtml
ui:param name=var1 value=value1/
/ui:composition
b.xhtml
ui:composition template=c.xhtml
ui:param name=var1 value=value1/
ui:param name=var2 value=value2/
/ui:composition
c.xhtml
ui:composition
h:outputText value=#{var1}/
h:outputText value=#{var2}/
/ui:composition
When facelet c.xhtml is constructed from a.xhtml, var2 is not recognized as
a parameter so all EL expressions inside c.xhtml holding refereces to var2
will be cached. Later, facelet c.xhtml is reused from b.xhtml but since
some EL expressions are cached the passed value in var2 is not taken into
account and the error arise.
In this point it is good to remember that ui:include or ui:decorate or user
tags are build view time tags, so they are executed only when the view is
built. Parameters or attributes passed by ui:param or as user tag attributes
follows the same principle, they are calculated on build view time through
VariableMapper and the evaluation is stored inside the EL Expression. This
means all EL Expressions holding references to these variables cannot be
cached and needs to be generated each time the view is built.
There is no way to know beforehand which references are affected, because
in a template or an user tag there is no declaration of the parameters or
attributes. But from user point of view that's good, because in this context
a declaration of the parameters is just not necessary.
The problem is ui:param and user tags are very useful features, widely used.
A solution to this problem will improve performance in those cases.
I have been thinking for a long time how to solve this, trying different
strategies. Use some kind of concurrency algorithm inside TagAttributeImpl
does not work because it is too expensive, or use a central storage for
cache the expressions by the cost involved in the comparisons.
The objective of cache EL expressions inside facelets abstract syntax tree
(AST) is minimize the calculations required to get a valid expression. EL
implementations has already an internal map that cache that information,
but that code usually has synchronized blocks or similar things. In that
sense, the idea is rely on that storage in those EL expressions where
there is no choice and they need to be recreated.
After doing many experiments in this part, I came up with a solution, which
involves the following points:
1. Associate to a facelet, the parameters that were considered as passed
through ui:param or as a user tag attribute. If in some point of time
we know for example c.xhtml uses var1, just consider it as c.xhtml(var1).
2. Use DefaultVariableMapper to track the parameters that are passed through
ui:param or as a user tag attribute. When the EL expression is created, if
it uses at least one parameter, mark the expression as not cacheable.
3. Override FaceletCache implementation and force a recompilation of a
facelet if a new parameter is detected that was not considered the first
time the template was created.
4. A facelet stored in the cache can be used if and only if all the
parameters used for the template where considered when it was compiled at
first time.
In the example proposed, when facelet c.xhtml is constructed from a.xhtml,
we say that c.xhtml was built with var1 as a known parameter, or
c.xhtml(var1). when we try to reuse facelet c.xhtml from b.xhtml, we discover
that var2 is also a parameter, but since the cached facelet is c.xhtml(var1),
the algorithm discard the facelet and create a new one, but taking into
account var2 too, so the new facelet becomes c.xhtml(var1,var2). If there
is a call to c.xhtml with no params, it
[jira] [Resolved] (MYFACES-3696) Button rendering itself after ajax request loses type and other attributes
[
https://issues.apache.org/jira/browse/MYFACES-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3696.
-
Resolution: Fixed
Fix Version/s: (was: 2.0.17)
(was: 2.1.11)
2.1.12
2.0.18
I have checked it again and it does not works only cases where
org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE is set to true and tomahawk
is present and autoscroll is on. It seems we need to include the check in that
location, but I prefer check both isPartialRequest() and isAjaxRequest()
(according to the spec both are different). Thanks Dennis for provide this
patch.
Button rendering itself after ajax request loses type and other attributes
--
Key: MYFACES-3696
URL: https://issues.apache.org/jira/browse/MYFACES-3696
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.10
Reporter: dennis hoersch
Assignee: Leonardo Uribe
Fix For: 2.0.18, 2.1.12
The renderer for command buttons and command links inserts a special form
submit script inline before the first button (or link) on a page is rendered
by calling
'org.apache.myfaces.shared.renderkit.html.HtmlJavaScriptUtils.renderFormSubmitScript(FacesContext)'
I have a CommandButton with ajax behavior that renders also itself like this:
h:form id=testForm
h:commandButton
value=do somethings
f:ajax execute=@this render=@this /
/h:commandButton
/h:form
After the ajax request is done and the markup is replaced by the Javascript
function _Dom.outerHtml() the html in the browser ends up with this:
input
type=text/javascript
onclick=...submit code ...
value= /
and is not a 'button' anymore (Firefox renders it as text input field).
The cause is that the update response for the button contains as first
element the inline script code.
Is it necessary to render the inline script on ajax requests?
Changing HtmlJavaScriptUtils to insert it only on non-ajax request the
example above works as expected at the first glance.
HtmlJavaScriptUtils.java
public static void renderFormSubmitScript(FacesContext facesContext)
throws IOException
{
if (facesContext.getPartialViewContext().isAjaxRequest())
{
return;
}
...
--
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] [Comment Edited] (MYFACES-3696) Button rendering itself after ajax request loses type and other attributes
[
https://issues.apache.org/jira/browse/MYFACES-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13635172#comment-13635172
]
Leonardo Uribe edited comment on MYFACES-3696 at 4/18/13 2:04 PM:
--
I have checked it again and it does not work only in cases where
org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE is set to true and tomahawk
is present and autoscroll is on. It seems we need to include the check in that
location, but I prefer check both isPartialRequest() and isAjaxRequest()
(according to the spec both are different). Thanks Dennis for provide this
patch.
was (Author: lu4242):
I have checked it again and it does not works only cases where
org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE is set to true and tomahawk
is present and autoscroll is on. It seems we need to include the check in that
location, but I prefer check both isPartialRequest() and isAjaxRequest()
(according to the spec both are different). Thanks Dennis for provide this
patch.
Button rendering itself after ajax request loses type and other attributes
--
Key: MYFACES-3696
URL: https://issues.apache.org/jira/browse/MYFACES-3696
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.10
Reporter: dennis hoersch
Assignee: Leonardo Uribe
Fix For: 2.0.18, 2.1.12
The renderer for command buttons and command links inserts a special form
submit script inline before the first button (or link) on a page is rendered
by calling
'org.apache.myfaces.shared.renderkit.html.HtmlJavaScriptUtils.renderFormSubmitScript(FacesContext)'
I have a CommandButton with ajax behavior that renders also itself like this:
h:form id=testForm
h:commandButton
value=do somethings
f:ajax execute=@this render=@this /
/h:commandButton
/h:form
After the ajax request is done and the markup is replaced by the Javascript
function _Dom.outerHtml() the html in the browser ends up with this:
input
type=text/javascript
onclick=...submit code ...
value= /
and is not a 'button' anymore (Firefox renders it as text input field).
The cause is that the update response for the button contains as first
element the inline script code.
Is it necessary to render the inline script on ajax requests?
Changing HtmlJavaScriptUtils to insert it only on non-ajax request the
example above works as expected at the first glance.
HtmlJavaScriptUtils.java
public static void renderFormSubmitScript(FacesContext facesContext)
throws IOException
{
if (facesContext.getPartialViewContext().isAjaxRequest())
{
return;
}
...
--
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-3705) Concurrency feature in FaceletCacheImpl
[
https://issues.apache.org/jira/browse/MYFACES-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13636058#comment-13636058
]
Leonardo Uribe commented on MYFACES-3705:
-
I have been thinking about this for a long time. Really the code is ok, use a
copy on write strategy works, but the evidence suggest that a
ConcurrentHashMap in that location will work too. There will not be any
difference from performance perspective, because the time spent compiling a
facelet or building a view or rendering a view is many times more than the lock
introduced by the map. Also the lock only happens when a facelet is added, so
once the facelet is compiled it will not be called anymore.
To be clear, the current code does not have any bug and it can be let as is.
But there is a problem with FaceletCache. MyFaces uses a special composite
component metadata facelet that the reference implementation does not have.
This means it is not possible to override fully how MyFaces handle facelet
instances, because there will be a part that is still done in
DefaultFaceletFactory.
I tried to include a change in JSF 2.2 spec related to that but there was no
success (it was considered implementation detail, really facelets algorithm has
not been standarized, because it is something complex). So, we need a custom
abstract class (AbstractFaceletCache) that extends from FaceletCache, but with
the additional methods, to allow people to create custom implementations
properly.
In my opinion, use a decoration pattern in this part does not work well,
because the logic behind the cache is not exposed by FaceletCache, or in other
words there are no explicit methods to force create facelets and store in the
cache, or refresh a facelet and so on.
Anyway, we need to create a custom AbstractFaceletCache and specify how to
implement it.
Concurrency feature in FaceletCacheImpl
-
Key: MYFACES-3705
URL: https://issues.apache.org/jira/browse/MYFACES-3705
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.1.0
Environment: All
Reporter: Pasi Salminen
Priority: Trivial
Original Estimate: 1h
Remaining Estimate: 1h
I'm implementing my own FaceletCache which is decorating
org.apache.myfaces.view.facelets.impl.FaceletCacheImpl by adding my own
caching policy. When I was studying the code I'm decorating, I noticed that
scrictly speaking it was not behaving. The problem lies in this code snippet
(and the same for metadata facelets):
if (_refreshPeriod != NO_CACHE_DELAY)
{
MapString, DefaultFacelet newLoc = new HashMapString,
DefaultFacelet(_facelets);
newLoc.put(key, f);
_facelets = newLoc;
}
First of all, multiple concurrent modifications of _facelets map may cause
lost updates. Think what happens when thread one copies the hashmap, updates
local copy but before it sets the reference, thread b does the same. One
update is now lost. In reality, the number of concurrent threads and number
of lost updates may be much larger. The second thing is that the new
reference set to _facelets is not quaranteed to be visible to other threads
due to missing synchronization. To prove my concerns, I created a small test
bench which proved my doubts and was able to show both lost updates and
visibility problem. When I modified the map to be ConcurrentHashMap and just
used put-method all problems vanished. So instead of
MapString, DefaultFacelet newLoc = new HashMapString,
DefaultFacelet(_facelets);
newLoc.put(key, f);
_facelets = newLoc;
I used
_facelets.put( key,f );
I know it may not be a problem, possibly just causing multiple loads of same
resource, but still I don't feel comfortable with the code behaving
concurrency-wise incorrectly.
BR, Paci
--
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-3708) NPE when no title using primefaces mobile
[ https://issues.apache.org/jira/browse/MYFACES-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3708. - Resolution: Fixed Fix Version/s: 2.1.12 2.0.18 Assignee: Leonardo Uribe I think add the null check doesn't harm. NPE when no title using primefaces mobile - Key: MYFACES-3708 URL: https://issues.apache.org/jira/browse/MYFACES-3708 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.10 Environment: primefaces 3.5, primefaces mobile 0.93, OWB 1.1.7, Tomcat 7 Reporter: Karl Kildén Assignee: Leonardo Uribe Priority: Minor Fix For: 2.0.18, 2.1.12 Primefaces mobile pages are described with pm:page and you can set title=your title. I don't want a title so I left the attribute out but that caused NPE. HtmlResponseWriterImpl 1018if (str.length() 0) The string in that case is null hence the length check causes NPE. Not sure if str != null should be added or not , maybe primefaces is doing something bad. Workaround is to use title= but it's not very pretty. -- 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-3402) Partial Response Writer always returns an ?xml version='1.0' encoding='utf-8'? ignoring the response encoding
[ https://issues.apache.org/jira/browse/MYFACES-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13634790#comment-13634790 ] Leonardo Uribe commented on MYFACES-3402: - ResourceHandlerImpl is not the one responsible to deal with the encoding in an ajax request. Checking this part, it seems the encoding is set in javax.faces.context.PartialResponseWriter.startDocument() and it is always utf-8. It looks like that part is wrong. The javadoc says: ... write the start of a partial response. so in that sense is right, but it should not write the xml preamble there. Instead, it should write the preamble in PartialViewContextImpl.processPartialRendering and take as content type the character encoding of the writer. Since this issue was not marked with component type JSR-314, it did not fell out of my radar. I'll check this one. Partial Response Writer always returns an ?xml version='1.0' encoding='utf-8'? ignoring the response encoding --- Key: MYFACES-3402 URL: https://issues.apache.org/jira/browse/MYFACES-3402 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.10, 2.1.4 Reporter: Werner Punz Attachments: JIRA-MYFACES-3402.patch While I was testing different ajax encodings I discovered that the Partial Response writer always returns the header listed on the headline of this issue. It ignores simply the original encoding. A blackbox test against Mojarra showed in that exact case the proper encoding not UTF-8 static. I guess the fix simply should be to make this part of the partial response writer more dynamic and to fetch the encoding in from the request header. -- 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-3709) metadata - component with duplicate id
[ https://issues.apache.org/jira/browse/MYFACES-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3709. - Resolution: Fixed Fix Version/s: 2.1.12 2.0.18 Assignee: Leonardo Uribe I have attached a patch with the correction. Thanks to Thomas Andraschko for provide the example. metadata - component with duplicate id -- Key: MYFACES-3709 URL: https://issues.apache.org/jira/browse/MYFACES-3709 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.11 Reporter: Thomas Andraschko Assignee: Leonardo Uribe Fix For: 2.0.18, 2.1.12 Attachments: MYFACES-3709.patch, my-webapp.7z Just run the attached project. Following exception occurs: java.lang.IllegalStateException: component with duplicate id j_id__md_1 found at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:100) at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:116) at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:110) at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:82) at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.saveView(DefaultFaceletsStateManagementStrategy.java:558) at org.apache.myfaces.application.StateManagerImpl.saveView(StateManagerImpl.java:188) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:2052) at org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285) at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199) This works fine if i remove the f:viewParam. -- 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-3704) Unable to find component when deployed on /demo/faces context
[ https://issues.apache.org/jira/browse/MYFACES-3704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619262#comment-13619262 ] Leonardo Uribe commented on MYFACES-3704: - Yes, that would be nice. When the issue is created I can jump in and provide the necessary information to make it work. Unable to find component when deployed on /demo/faces context - Key: MYFACES-3704 URL: https://issues.apache.org/jira/browse/MYFACES-3704 Project: MyFaces Core Issue Type: Bug Reporter: Manfred Riem To reproduce: 1. Download http://www.manorrock.com/repo/org/manorrock/faces/org-manorrock-faces-demo/2.1.1.0.0/ 2. Deploy to /demo/faces on Tomcat It throws an exception. It should work. If you need more information please let me know! -- 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] (TOMAHAWK-1661) dataTable value evaluated if parent component not rendered if preserveDataModel is true
[
https://issues.apache.org/jira/browse/TOMAHAWK-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13616480#comment-13616480
]
Leonardo Uribe commented on TOMAHAWK-1661:
--
preserveDataModel forces save the dataModel into the state, and in that way,
getValue() must be called. There is no way to avoid this, because rendered
attribute has nothing to do with the state saving algorithm.
I can see the logic behind this. If the component is not rendered, there should
not be dataModel to store and in that way getValue() does not need to be
called. Only if there is a dataModel before save state, it has sense to save it.
I think the solution could be check if there is a dataModel and
preserveDataModel is active save it, otherwise do not do nothing.
Thinking about this, I realized that in case of a nested dataTable with
preserveDataModel set to true, it is better that the inner declaration does not
have any effect, because the top level dataModel contains the information of
the inner dataModel too.
dataTable value evaluated if parent component not rendered if
preserveDataModel is true
---
Key: TOMAHAWK-1661
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1661
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.14
Reporter: John Smith
If a t:dataTable's parent component's rendered attribute evaluates to false,
the dataTable's value attribute is still evaluated if the dataTable has the
preserveDataModel attribute set to true.
While I don't think this strictly violates the spec (it says under 2.2.6: 'If
the isRendered() method of a component returns false, the renderer for that
component must not generate any markup, and none of its facets or children
(if any) should be rendered.'), it is at the very least inconsistent with
other JSF components, which do not evaluate the value if not rendered
Example:
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:t=http://myfaces.apache.org/tomahawk;
h:head /
h:body
h:form
h:panelGroup rendered=false
t:dataTable value=#{bean.list} var=list
preserveDataModel=true
h:column#{list}/h:column
/t:dataTable
/h:panelGroup
/h:form
/h:body
/html
-
@RequestScoped
@ManagedBean
public class Bean {
public ListString getList(){
throw new RuntimeException(this should not be called);
}
}
--
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] (MYFACES-3586) Performance improvement in Resource loading - HIGH CPU inflating bytes in ResourceHandlerImpl.handleResourceRequest
[ https://issues.apache.org/jira/browse/MYFACES-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3586: Resolution: Fixed Fix Version/s: 2.1.11 Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) Closing this issue as fixed, since there is no objections and instead the is interest to get this one done. It was only committed the fix using a temporal folder (no mem cache). Performance improvement in Resource loading - HIGH CPU inflating bytes in ResourceHandlerImpl.handleResourceRequest --- Key: MYFACES-3586 URL: https://issues.apache.org/jira/browse/MYFACES-3586 Project: MyFaces Core Issue Type: Improvement Environment: ALL Reporter: Rohit Dilip Kelapure Assignee: Leonardo Uribe Fix For: 2.1.11 Attachments: MYFACES-3586-1.patch, MYFACES-3586.patch Original Estimate: 48h Remaining Estimate: 48h In a high concurrency load test with Apache MyFaces + RichFaces component library we found that under peak load majority of our web container threads were stuck in this call stack at java/util/zip/Inflater.inflateBytes(Native Method) at java/util/zip/Inflater.inflate(Inflater.java:249(Compiled Code)) at java/util/zip/InflaterInputStream.read(InflaterInputStream.java:146(Compiled Code)) at java/util/zip/InflaterInputStream.read(InflaterInputStream.java:116(Compiled Code)) at java/io/FilterInputStream.read(FilterInputStream.java:77(Compiled Code)) at java/io/FilterInputStream.read(FilterInputStream.java:77(Compiled Code)) at java/io/PushbackInputStream.read(PushbackInputStream.java:133(Compiled Code)) at org/apache/myfaces/shared_impl/resource/ResourceImpl$ValueExpressionFilterInputStream.read(ResourceImpl.java:117(Compiled Code)) at java/io/InputStream.read(InputStream.java:175(Compiled Code)) at java/io/InputStream.read(InputStream.java:97(Compiled Code)) at org/apache/myfaces/application/ResourceHandlerImpl.pipeBytes(ResourceHandlerImpl.java:402(Compiled Code)) at org/apache/myfaces/application/ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:357(Compiled Code)) at org/richfaces/resource/ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:257(Compiled Code)) at javax/faces/webapp/FacesServlet.service(FacesServlet.java:183(Compiled Code)) at org/richfaces/webapp/ResourceServlet.httpService(ResourceServlet.java:110(Compiled Code)) at org/richfaces/webapp/ResourceServlet.service(ResourceServlet.java:105(Compiled Code)) After looking at the src code of org.apache.myfaces.application.ResourceHandlerImpl.handleResourceRequest(FacesContext) I can see that the ResourceHandlerCache caches the Resource metadata ; however the actual output of the resource which is written to the outputstream in ResourceHandlerImpl.pipeBytes is NEVER cached. This causes a scalability problem in our case because each access to the resource involves cracking open a jar, inflating the bytes and parsing a stream of bytes. This is done multiple times for the same resource(say a css file) inside the richfaces jar inspite of the resource not changing. I propose a much needed performance optimization wherein we cache the output of the Resource handled and stash the output byte[] it as softReference in the ResourceHandlerCache.ResourceValue. -- 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-3695) 'Cannot set header. Response already committed.' on WebSphere Application Server 7 and 8
[
https://issues.apache.org/jira/browse/MYFACES-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3695.
-
Resolution: Fixed
Fix Version/s: 2.1.11
2.0.17
Assignee: Leonardo Uribe
It seems the easiest solution is check if the response has been committed and
if not, write the content lenght, otherwise continue. Since the change was done
in mojarra, I suppose it is ok to apply it in myfaces too.
'Cannot set header. Response already committed.' on WebSphere Application
Server 7 and 8
Key: MYFACES-3695
URL: https://issues.apache.org/jira/browse/MYFACES-3695
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.1.10
Environment: WebSphere Application Server 7 or 8
Reporter: Jack van Ooststroom
Assignee: Leonardo Uribe
Fix For: 2.0.17, 2.1.11
When trying to handle a resource using the default implementation of
ResourceHandler, namely ResourceHandlerImpl, a warning message is logged when
running on WebSphere Application Server 7 or 8:
W com.ibm.ws.webcontainer.srt.SRTServletResponse setIntHeader SRVE8094W:
WARNING: Cannot set header. Response already committed.
Looking at the code of ResourceHandlerImpl.handleResourceRequest(FacesContext
context) I found the following snippet:
try
{
InputStream in = resource.getInputStream();
OutputStream out = httpServletResponse.getOutputStream();
//byte[] buffer = new byte[_BUFFER_SIZE];
byte[] buffer = new byte[this.getResourceBufferSize()];
try
{
int count = pipeBytes(in, out, buffer);
//set the content lenght
httpServletResponse.setContentLength(count);
}
finally
{
try
{
in.close();
}
finally
{
out.close();
}
}
}
If the resource is small enough and the buffer limit is not reached
everything should be fine (default size seems 2048), however if the resource
is bigger the buffer gets flushed WebSphere Application Server will use
chunked encoding and the httpServletResponse.setContentLength(count) gets
executed after the fact resulting in the mentioned message. Setting the
org.apache.myfaces.RESOURCE_BUFFER_SIZE context parameter is a possible
workaround, but it would be better to avoid this as resource sizes can be
unpredictable.
--
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-3659) Conditional include of scripts and stylesheets
[
https://issues.apache.org/jira/browse/MYFACES-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3659.
-
Resolution: Fixed
Fix Version/s: 2.1.11
2.0.17
Assignee: Leonardo Uribe
Added junit test case to myfaces (thanks to Dennis Hoersch for provide this
patch). The javadoc was updated too.
Conditional include of scripts and stylesheets
---
Key: MYFACES-3659
URL: https://issues.apache.org/jira/browse/MYFACES-3659
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.6
Environment: MyFaces 2.1.6, Tomahawk20 1.1.11
Reporter: dennis hoersch
Assignee: Leonardo Uribe
Fix For: 2.0.17, 2.1.11
Attachments: MYFACES-3659_2.diff, MYFACES-3659_2.zip,
MYFACES-3659_3.diff, MYFACES-3659-3.patch, MYFACES-3659-4.patch,
patch-MYFACES-3659.diff, patch-MYFACES-3659.zip, test-MYFACES-3659.zip
I am inserting a script 'X.js' dependent on a condition (c:if). The default
case is to include it. If I change the underlying value within an action so
that the condition evaluates to false, the script is still included. Also
after any other following action.
Using F5 in Firefox the page is now rendered without the script.
The script 'X.js' was added to the view root and is never 'forgot' or
removed. It is the same if the script is included in a composite component.
In that case I even observed that the order of the scripts changes and the
script 'X.js' is included before other basic scripts like jQuery on which
'X.js' depends.
h:form id=form
c:set var=sessionScope
value=#{facesContext.externalContext.sessionMap} /
h:commandButton value=deactivate
rendered=#{empty sessionScope.__isActive_ or
sessionScope.__isActive_}
f:setPropertyActionListener target=#{sessionScope.__isActive_}
value=#{false} /
/h:commandButton
h:commandButton value=activate
rendered=#{not empty sessionScope.__isActive_ and not
sessionScope.__isActive_}
f:setPropertyActionListener target=#{sessionScope.__isActive_}
value=#{true} /
/h:commandButton
h:commandButton value=do nothing /
h:outputScript library=js name=jQuery.js target=body /
c:if test=#{empty sessionScope.__isActive_ or sessionScope.__isActive_}
BLA
h:outputScript library=js name=X.js target=body /
/c:if
/h:form
Am I doing something wrong? Is there another (or better) way to include
scripts conditionally?
(
If I change 'HtmlOutputScriptHandler' to set the script transient, it works
in the first glance, but I don't know the impact...
@Override
public void onComponentPopulated(FaceletContext ctx, UIComponent c,
UIComponent parent) {
super.onComponentPopulated(ctx, c, parent);
c.setTransient(true);
}
)
--
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-3660) Component resource added using @ResourceDependency annotation from a facelet component should have an id defined by facelets
[ https://issues.apache.org/jira/browse/MYFACES-3660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3660. - Resolution: Fixed Fix Version/s: 2.1.11 2.0.17 I checked this one and with the fixes done in MYFACES-3663, MYFACES-3665 and MYFACES-3668 we can close this one as fixed Component resource added using @ResourceDependency annotation from a facelet component should have an id defined by facelets Key: MYFACES-3660 URL: https://issues.apache.org/jira/browse/MYFACES-3660 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.17, 2.1.11 A problem related to @ResourceDependency has been mentioned on: http://stackoverflow.com/questions/13526624/duplicate-id-error-with-partial-state-saving-and-myfaces-codi CODI add a component called WindowContextIdHolderComponent in ResponseWriter.startDocument(), and later a UIViewRoot.createUniqueId() call is done when getClientId() is called from the code that checks for duplicate ids. The problem is the code that process @ResourceDependency annotations in ApplicationImpl object let UIViewRoot.addComponentResource() internals to call createUniqueId(). In the example proposed, there is a dynamic block that changes the resources added at an specific moment of time, and since by PSS saving algorithm, restore view phase calls buildView() before restore the initial state, the count of uniqueIdCounter in UIViewRoot is never restored, and there is a chance that the same id of the one assigned to WindowContextIdHolderComponent can be set to a component resource added by @ResourceDependency effect. The problem of how generate ids is well known and has been studied for a long time. A general solution for facelets was committed in MYFACES-3329, and has worked well so far. In few words, we need to generate predictable component ids to make PSS algorithm reliable, otherwise it will be problems related to state saving that are very difficult to track down and solve. In the other hand, PSS algorithm impose some restrictions over the view that conflicts with dynamic manipulations of the component tree. I think the solution for this one is ensure all components created inside facelets vdl.buildView has unique ids, doing some changes over UIViewRoot.createUniqueId and changing @ResourceDependency processing in ApplicationImpl, so if facelets is processing the current view use FaceletCompositionContext.generateUniqueComponentId() to set an Id. Since @ResourceDependency depends on the component tree structure, the ids will now contains the information related to the tree structure itself (in the generated id), preventing duplicates. In theory, if we can ensure that all components generated by facelets has a component id defined by facelets algorithm, createUniqueId will be let to components added programatically, so we can do some hack to restore the uniqueIdCounter for UIViewRoot on restore view phase before call vdl.buildView, and simulate the same behavior we had in JSF 1.2, without the side effects over the state and performance. I think solutions using a HashMap using duplicates or random generators are out of discussion, because they will not ensure the predictability we need to get correct operation of PSS algorithm. -- 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-3696) Button rendering itself after ajax request loses type and other attributes
[
https://issues.apache.org/jira/browse/MYFACES-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615882#comment-13615882
]
Leonardo Uribe commented on MYFACES-3696:
-
The bug is on org.apache.myfaces.shared.renderkit.html.util.ResourceUtils . The
check is done on renderMyfacesJSInlineIfNecessary() but using
facesContext.getPartialViewContext().isPartialRequest(), and not using
facesContext.getPartialViewContext().isAjaxRequest() . In
renderDefaultJsfJsInlineIfNecessary(), isAjaxRequest() is used. The right thing
to do is check both isPartialRequest() or isAjaxRequest() . MyFaces code has an
alternative by backward compatibility that render the submit script inline, so
we should not do the check in that location.
Button rendering itself after ajax request loses type and other attributes
--
Key: MYFACES-3696
URL: https://issues.apache.org/jira/browse/MYFACES-3696
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.10
Reporter: dennis hoersch
The renderer for command buttons and command links inserts a special form
submit script inline before the first button (or link) on a page is rendered
by calling
'org.apache.myfaces.shared.renderkit.html.HtmlJavaScriptUtils.renderFormSubmitScript(FacesContext)'
I have a CommandButton with ajax behavior that renders also itself like this:
h:form id=testForm
h:commandButton
value=do somethings
f:ajax execute=@this render=@this /
/h:commandButton
/h:form
After the ajax request is done and the markup is replaced by the Javascript
function _Dom.outerHtml() the html in the browser ends up with this:
input
type=text/javascript
onclick=...submit code ...
value= /
and is not a 'button' anymore (Firefox renders it as text input field).
The cause is that the update response for the button contains as first
element the inline script code.
Is it necessary to render the inline script on ajax requests?
Changing HtmlJavaScriptUtils to insert it only on non-ajax request the
example above works as expected at the first glance.
HtmlJavaScriptUtils.java
public static void renderFormSubmitScript(FacesContext facesContext)
throws IOException
{
if (facesContext.getPartialViewContext().isAjaxRequest())
{
return;
}
...
--
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-3696) Button rendering itself after ajax request loses type and other attributes
[
https://issues.apache.org/jira/browse/MYFACES-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3696.
-
Resolution: Fixed
Fix Version/s: 2.1.11
2.0.17
Assignee: Leonardo Uribe
Button rendering itself after ajax request loses type and other attributes
--
Key: MYFACES-3696
URL: https://issues.apache.org/jira/browse/MYFACES-3696
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.10
Reporter: dennis hoersch
Assignee: Leonardo Uribe
Fix For: 2.0.17, 2.1.11
The renderer for command buttons and command links inserts a special form
submit script inline before the first button (or link) on a page is rendered
by calling
'org.apache.myfaces.shared.renderkit.html.HtmlJavaScriptUtils.renderFormSubmitScript(FacesContext)'
I have a CommandButton with ajax behavior that renders also itself like this:
h:form id=testForm
h:commandButton
value=do somethings
f:ajax execute=@this render=@this /
/h:commandButton
/h:form
After the ajax request is done and the markup is replaced by the Javascript
function _Dom.outerHtml() the html in the browser ends up with this:
input
type=text/javascript
onclick=...submit code ...
value= /
and is not a 'button' anymore (Firefox renders it as text input field).
The cause is that the update response for the button contains as first
element the inline script code.
Is it necessary to render the inline script on ajax requests?
Changing HtmlJavaScriptUtils to insert it only on non-ajax request the
example above works as expected at the first glance.
HtmlJavaScriptUtils.java
public static void renderFormSubmitScript(FacesContext facesContext)
throws IOException
{
if (facesContext.getPartialViewContext().isAjaxRequest())
{
return;
}
...
--
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-3704) Unable to find component when deployed on /demo/faces context
[ https://issues.apache.org/jira/browse/MYFACES-3704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615893#comment-13615893 ] Leonardo Uribe commented on MYFACES-3704: - I tried with Apache TomEE 1.5.1. It works with the latest snapshot. I checked the code that scans for annotations and it is correct. Note in some known cases, the default annotation scanner could not work as expected (because the underlying server could use something special like for example in jboss the virtual file system and so on), but for that there is an SPI interface (org.apache.myfaces.spi.AnnotationProvider) that helps with that. Unable to find component when deployed on /demo/faces context - Key: MYFACES-3704 URL: https://issues.apache.org/jira/browse/MYFACES-3704 Project: MyFaces Core Issue Type: Bug Reporter: Manfred Riem To reproduce: 1. Download http://www.manorrock.com/repo/org/manorrock/faces/org-manorrock-faces-demo/2.1.1.0.0/ 2. Deploy to /demo/faces on Tomcat It throws an exception. It should work. If you need more information please let me know! -- 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-3704) Unable to find component when deployed on /demo/faces context
[ https://issues.apache.org/jira/browse/MYFACES-3704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13616050#comment-13616050 ] Leonardo Uribe commented on MYFACES-3704: - I have deployed the application uncompressing the war and removing the duplicate libraries in WEB-INF/lib folder (if any, but the war file does not have none). Probably in this case, the problem is caused by TomEE, when the file is deployed on the server. The default algorithm follows JSF spec, but it could be possible that when the list of files under WEB-INF/lib is retrieved by the annotation provider, the related files that needs to be scanned for annotations are not retrieved and in that way the scanning is not done. In that case there are these options: 1. write a custom AnnotationProvider that match with TomEE in this case. 2. try to fix the problem directly in TomEE 3. use org.apache.myfaces.annotation.SCAN_PACKAGES config param and indicate the packages that needs to be scanned for annotations. See http://myfaces.apache.org/core21/myfaces-impl/webconfig.html for details. Unable to find component when deployed on /demo/faces context - Key: MYFACES-3704 URL: https://issues.apache.org/jira/browse/MYFACES-3704 Project: MyFaces Core Issue Type: Bug Reporter: Manfred Riem To reproduce: 1. Download http://www.manorrock.com/repo/org/manorrock/faces/org-manorrock-faces-demo/2.1.1.0.0/ 2. Deploy to /demo/faces on Tomcat It throws an exception. It should work. If you need more information please let me know! -- 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-3702) ui:repeat is caching its data model if error occurs
[
https://issues.apache.org/jira/browse/MYFACES-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13614595#comment-13614595
]
Leonardo Uribe commented on MYFACES-3702:
-
I don't remember if there is an issue created in the spec issue tracker:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC
In theory there is a dependency between the row state and the data model. In
this case, the description in the javadoc must be respected.
The only alternative is do something in tomahawk t:dataList or t:dataTable to
alter the default behavior, but anyway it is necessary to specify the
conditions over the dataModel is cleared in encodeBegin(). One idea could be
introduce an attribute that instead check for a FacesMessage in the stack, it
checks if there is a validation error (FacesContext.isValidationFailed() ), and
if that so do not clear the dataModel, otherwise do it. We need a good name for
that attribute too. I think something like that could work.
ui:repeat is caching its data model if error occurs
Key: MYFACES-3702
URL: https://issues.apache.org/jira/browse/MYFACES-3702
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.10
Reporter: dennis hoersch
ui:repeat caches its data model. Usually it it is cleared before rendering.
But not if there are any errors in faces context.
Why is it not cleared then?
That causes a problem in the following scenario:
We have an ui:repeat that iterating over a list of more detailed error
messages of an object on the page. This list is empty in the start of an
request. While invoking an action on the page error messages are added to the
faces context to be shown on the page. Additionally some more detailed
information is stored to be shown directly with that object.
But they won't appear because the empty list is cached in the ui:repeat's
data model.
I could reproduce it with the following more general example: The first
button creates an info message which will be shown by the ui:repeat. The
second button creates an error message and nothing is rendered through the
ui:repeat.
Testpage.xhtml
his:form id=testForm
h:commandButton value=Create info message
action=#{testController.createInfoMessage()} /
h:commandButton value=Create error message
action=#{testController.createErrorMessage()} /
br/
UI:Repeat:
ui:repeat var=item value=#{facesContext.getMessageList()}
FacesMessage #{item.severity} // #{item.summary}
/ui:repreat|br/
Has Messages: #{not empty facesContext.getMessageList()}|
/his:form
TestController
public void createErrorMessage() {
MessageUtils.addMessage(FacesMessage.SEVERITY_ERROR, Oh no, an error!,
new Object[] {});
}
public void createInfoMessage() {
MessageUtils.addMessage(FacesMessage.SEVERITY_INFO, Just an information.,
new Object[] {});
}
--
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-3586) Performance improvement in Resource loading - HIGH CPU inflating bytes in ResourceHandlerImpl.handleResourceRequest
[ https://issues.apache.org/jira/browse/MYFACES-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13599392#comment-13599392 ] Leonardo Uribe commented on MYFACES-3586: - I would say the patch is ok to commit it, but the solution using a memory cache still doesn't sound too convincing. The reason is this looks just like replicate the same work done in apache server, so if you really need something like that, do the logic in apache server. Anyway, if there is no objections, I can commit the code and include it in the next release. The patch suppose include a web config param: org.apache.myfaces.TEMPORAL_RESOURCEHANDLER_CACHE_ENABLED by default false to enable/disable it. In theory the patch as is is ok and becomes useful, but I would like to hear other opinions, to see how far is really necessary to go. Performance improvement in Resource loading - HIGH CPU inflating bytes in ResourceHandlerImpl.handleResourceRequest --- Key: MYFACES-3586 URL: https://issues.apache.org/jira/browse/MYFACES-3586 Project: MyFaces Core Issue Type: Improvement Environment: ALL Reporter: Rohit Dilip Kelapure Attachments: MYFACES-3586-1.patch, MYFACES-3586.patch Original Estimate: 48h Remaining Estimate: 48h In a high concurrency load test with Apache MyFaces + RichFaces component library we found that under peak load majority of our web container threads were stuck in this call stack at java/util/zip/Inflater.inflateBytes(Native Method) at java/util/zip/Inflater.inflate(Inflater.java:249(Compiled Code)) at java/util/zip/InflaterInputStream.read(InflaterInputStream.java:146(Compiled Code)) at java/util/zip/InflaterInputStream.read(InflaterInputStream.java:116(Compiled Code)) at java/io/FilterInputStream.read(FilterInputStream.java:77(Compiled Code)) at java/io/FilterInputStream.read(FilterInputStream.java:77(Compiled Code)) at java/io/PushbackInputStream.read(PushbackInputStream.java:133(Compiled Code)) at org/apache/myfaces/shared_impl/resource/ResourceImpl$ValueExpressionFilterInputStream.read(ResourceImpl.java:117(Compiled Code)) at java/io/InputStream.read(InputStream.java:175(Compiled Code)) at java/io/InputStream.read(InputStream.java:97(Compiled Code)) at org/apache/myfaces/application/ResourceHandlerImpl.pipeBytes(ResourceHandlerImpl.java:402(Compiled Code)) at org/apache/myfaces/application/ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:357(Compiled Code)) at org/richfaces/resource/ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:257(Compiled Code)) at javax/faces/webapp/FacesServlet.service(FacesServlet.java:183(Compiled Code)) at org/richfaces/webapp/ResourceServlet.httpService(ResourceServlet.java:110(Compiled Code)) at org/richfaces/webapp/ResourceServlet.service(ResourceServlet.java:105(Compiled Code)) After looking at the src code of org.apache.myfaces.application.ResourceHandlerImpl.handleResourceRequest(FacesContext) I can see that the ResourceHandlerCache caches the Resource metadata ; however the actual output of the resource which is written to the outputstream in ResourceHandlerImpl.pipeBytes is NEVER cached. This causes a scalability problem in our case because each access to the resource involves cracking open a jar, inflating the bytes and parsing a stream of bytes. This is done multiple times for the same resource(say a css file) inside the richfaces jar inspite of the resource not changing. I propose a much needed performance optimization wherein we cache the output of the Resource handled and stash the output byte[] it as softReference in the ResourceHandlerCache.ResourceValue. -- 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
