Thanks for the info, Blake! Leo, please take a look at my comment + patch on MYFACES-2942. I did exactly what you just said and I fully agree with you! If there are no objections to that patch, I'll commit it tomorrow!
Regards, Jakob 2010/10/15 Leonardo Uribe <lu4...@gmail.com>: > Hi > > Checking this issue, I think we should just get rid of that ThreadLocal var, > because it is used as a hack to pass the right RuntimeConfig instance. > Before JSF 2.0 this was required because there was not startup FacesContext, > but now it exists, so it is valid to get the current ExternalContext and > then the valid RuntimeConfig from application map. Maybe we should update > jsf 1.2 branch to include the same concept. > > regards, > > Leonardo Uribe > > 2010/10/15 Blake Sullivan <blake.sulli...@oracle.com> >> >> You guys might want to check out the utility that Trinidad uses for >> registering ThreadLocals for clean up at the end of the request in >> org.apache.myfaces.trinidad.util.ThreadLocalUtils. >> >> -- Blake Sullivan >> >> On 10/15/10 5:52 AM, Jakob Korherr wrote: >>> >>> Thanks, Stan! >>> >>> We had a similar issue also in OpenWebBeans. The solution there was to >>> clear() all ThreadLocals after usage, however not only in the >>> ServletContextListener, but also in the RequestListener, because >>> ThreadLocal.clear() only works for the current Thread. Thus we have to >>> take a look at all our ThreadLocal instances in the code and check if >>> they can be set at request time. If so, we may have to clear them at >>> the end of every request. >>> >>> Regards, >>> Jakob >>> >>> 2010/10/15<ssilv...@redhat.com>: >>>> >>>> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820 >>>> >>>> Quoting Werner Punz<werner.p...@gmail.com>: >>>> >>>>> Stan can you give us some info what the issue in Mojarra was? >>>>> It might help us to track our problem down. >>>>> My personal guess we that it might the our class instantiation code in >>>>> shared, but I am guessing here as well. >>>>> >>>>> >>>>> Werner >>>>> >>>>> >>>>> Am 15.10.10 14:04, schrieb ssilv...@redhat.com: >>>>>> >>>>>> 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. >>>>>> >>>>>> Stan >>>>>> >>>>>> Quoting Matthias Wessendorf<mat...@apache.org>: >>>>>> >>>>>>> On Fri, Oct 15, 2010 at 10:15 AM, Werner Punz<werner.p...@gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> Am 15.10.10 09:26, schrieb Matthias Wessendorf: >>>>>>>> >>>>>>>>>> Right now it has MyFaces 2.0.1, but I'm soon planning to do the >>>>>>>>>> full >>>>>>>>>> integration of 2.0.2 as per Leonardo's changes. That will make >>>>>>>>>> MyFaces a >>>>>>>>>> little more efficient on JBoss AS. >>>>>>>>> >>>>>>>>> +1 you really want 2.0.2 ;) >>>>>>>>> >>>>>>>> Hehe I guess Myfaces 2.0.2 performance also will be better due to >>>>>>>> the >>>>>>>> performance work which went in between 2.0.1 and 2.0.2. >>>>>>> >>>>>>> that's why ;) >>>>>>> >>>>>>>> Werner >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matthias Wessendorf >>>>>>> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> > > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
