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 <[email protected]> > 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<[email protected]>: >> >>> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820 >>> >>> Quoting Werner Punz<[email protected]>: >>> >>> 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 [email protected]: >>>> >>>>> 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<[email protected]>: >>>>> >>>>> On Fri, Oct 15, 2010 at 10:15 AM, Werner Punz<[email protected]> >>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> >>> >> >> >
