[jira] [Commented] (MYFACES-3716) Implement h:inputFile

2013-06-23 Thread Leonardo Uribe (JIRA)

[ 
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] [Created] (MYFACES-3739) @ResourceDependency annotation can cause Memory leak (UIViewRoot grows)

2013-06-23 Thread Andrei Zhemaituk (JIRA)
Andrei Zhemaituk created MYFACES-3739:
-

 Summary: @ResourceDependency annotation can cause Memory leak 
(UIViewRoot grows)
 Key: MYFACES-3739
 URL: https://issues.apache.org/jira/browse/MYFACES-3739
 Project: MyFaces Core
  Issue Type: Bug
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] [Commented] (MYFACES-3739) @ResourceDependency annotation + JSF 1.2 state saving + c:if (dynamic section) creates components on each click (UIViewRoot grows)

2013-06-23 Thread Leonardo Uribe (JIRA)

[ 
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