[ 
https://issues.apache.org/jira/browse/MYFACES-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13693401#comment-13693401
 ] 

Andrei Zhemaituk edited comment on MYFACES-3739 at 6/25/13 9:38 PM:
--------------------------------------------------------------------

Leonardo,
Thanks for quick feedback and great problem analysis!.
I have tried the patch and the issue is not reproducible with either RichFaces 
example (RF-13025) or pure myfaces example (with c:if one).
Just a note that the issue is much easier to reproduce with RichFaces. Just 
having a4j:ajax on page is enough (its tag handler calls 
Application#createBehavior on every build tree which in turn process 
AjaxBehaviorRenderer's annotations), example is as simple as:
{code:xml}
<h:form>
<h:commandButton value="Click Me">
    <a4j:ajax execute="@this" render="@this"/>
</h:commandButton>
</h:form>
{code}

With the patch there is still an issue when there are different components 
referencing the same resource. It does not cause memory leak but still keeps 
some resource duplicates (one per component class).

{code:xml}
<h:form>
    <h:commandButton value="Toggle" 
action="#{sessionScopedBean.togglePanelShown}">
        <f:ajax execute="@this" render="group"/>
    </h:commandButton>

    <custom:componentWithResourceDependency/>
    <h:panelGroup id="group">
        <c:if test="#{sessionScopedBean.panelShown}">
            #{sessionScopedBean.panelShown}
            <custom:anotherComponentWithSameResourceDependency/>
        </c:if>
    </h:panelGroup>
</h:form>
{code}

If the panel is initially shown (both components are in the tree) - resource 
(UIOutput) gets added only once to the tree.
If the panel is not shown - resource gets added, after clicking the button - 
resource gets added once again.

I guess it can be solved by storing added resource dependencies 
(org.apache.myfaces.context.RequestViewContext#addedResources) in the same way 
as processed classes are stored in your solution. Probably it will add some 
more of memory overhead (but it potentially saves some on eliminating 
duplicates). Also having added resource dependencies saved removes the need of 
having processed classes stored, not keeping processed classes would save the 
mentioned by you 80-150 bytes but will add I guess a bit of CPU overhead on 
every request for reading classes annotations.
                
      was (Author: andreyz):
    Leonardo,
Thanks for quick feedback and great problem analysis!.
I have tried the patch and the issue is not reproducible with either RichFaces 
example (RF-13025) or pure myfaces example (with c:if one).
Just a note that the issue is much easier to reproduce with RichFaces. Just 
having a4j:ajax on page is enough (its tag handler calls 
Application#createBehavior on every build tree which in turn process 
AjaxBehaviorRenderer's annotations), example is as simple as:
{code}
<h:form>
<h:commandButton value="Click Me">
    <a4j:ajax execute="@this" render="@this"/>
</h:commandButton>
</h:form>
{code}

With the patch there is still an issue when there are different components 
referencing the same resource. It does not cause memory leak but still keeps 
some resource duplicates (one per component class).

{code}
<h:form>
    <h:commandButton value="Toggle" 
action="#{sessionScopedBean.togglePanelShown}">
        <f:ajax execute="@this" render="group"/>
    </h:commandButton>

    <custom:componentWithResourceDependency/>
    <h:panelGroup id="group">
        <c:if test="#{sessionScopedBean.panelShown}">
            #{sessionScopedBean.panelShown}
            <custom:anotherComponentWithSameResourceDependency/>
        </c:if>
    </h:panelGroup>
</h:form>
{code}

If the panel is initially shown (both components are in the tree) - resource 
(UIOutput) gets added only once to the tree.
If the panel is not shown - resource gets added, after clicking the button - 
resource gets added once again.

I guess it can be solved by storing added resource dependencies 
(org.apache.myfaces.context.RequestViewContext#addedResources) in the same way 
as processed classes are stored in your solution. Probably it will add some 
more of memory overhead (but it potentially saves some on eliminating 
duplicates). Also having added resource dependencies saved removes the need of 
having processed classes stored, not keeping processed classes would save the 
mentioned by you 80-150 bytes but will add I guess a bit of CPU overhead on 
every request for reading classes annotations.
                  
> @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

Reply via email to