[
https://issues.apache.org/jira/browse/MYFACES-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923145#action_12923145
]
Jakob Korherr commented on MYFACES-2942:
----------------------------------------
Hi Leo,
Sorry for the late answer.
> I see that my suggestion about "clear" the map was not very clear. I was
> thinking on add some code inside
> org.apache.myfaces.webapp.AbstractFacesInitializer.destroyFaces(ServletContext)
> to do proper cleanup (if you have a WeakHashMap somewhere, call a method
> that removes the key).
> For the case of MetaRulesetImpl, I think use a WeakHashMap and do proper
> cleanup on AbstractFacesInitializer.destroyFaces is better. There is no
> reason to call FacesContext.getCurrentInstance(), since the returned
> instances are "application scope" and once initialized does not change.
You're right, Leo. In this case it might be better to use the static
WeakHashMap<ClassLoader, WeakHashMap<String, MetadataTarget>> and ensure a
cleanup on application shutdown. This will be faster. The reason I put this on
ApplicationMap was simply to use the advantage of ApplicationMap beeing cleared
automatically. I'll change this.
> There are valid cases where ThreadLocal usage is required. For example, in
> FlashELResolver it is possible that an EL expression could be resolved
> outside normal JSF lifecycle, where there is no FacesContext set, so the code
> committed will not work as expected. The same applies for
> VariableResolverToELResolver, so that code must be reverted to its original
> form.
I disagree, because the FlashELResolver only makes sence for JSF and it
actually really does use the FacesContext, however indirectly, because it gets
the ExternalContext via the FacesContext. So if you have no FacesContext at all
the FlashElResolver will fail no matter what (no FacesContext means no
ExternalContext means no Flash). Furthermore you can't really remove() the
ThreadLocal in FlashELResolver in a consistent way other than using an
additional request-listener. I think that using the FacesContext here instead
of the ThreadLocal is a better alternative, but please feel free to convince me
otherwise!
Jakob
> Memory Leak in MyFaces 2.0.1 probably as well in 2.0.2
> ------------------------------------------------------
>
> Key: MYFACES-2942
> URL: https://issues.apache.org/jira/browse/MYFACES-2942
> Project: MyFaces Core
> Issue Type: Bug
> Affects Versions: 2.0.1, 2.0.2
> Environment: JBOSS AS
> Reporter: Werner Punz
> Assignee: Jakob Korherr
> Priority: Critical
> Attachments: MYFACES-2942-RuntimeConfig.patch
>
>
> Stan Silvert from JBoss reports:
> I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy
> leak and it took a long time to track it down. The same test I was using on
> Mojarra also failed on MyFaces but I haven't had time to track down the leak
> in MyFaces.
> Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a
> look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all
> you need to do is create a small exploaded JSF app. Then have a script that
> touches web.xml every 10 seconds. That will cause the app to redeploy. You
> will get a PermGen error in about an hour.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
