Greg Dick added a comment - 26/Jun/08 10:33 AM From Mark C. message #1 I remember reading about this on the Facelets mailing list. Basically, DefaultFaceletFactory, which extends FaceletFactory, does all of the parsing of the .xhtml files into Facelet objects, and also caches them. But there's no actual limit on the cache. The good news is that it's bounded by the number of .xhtml files, so it won't leak forever, unless they're auto-generating .xhtml files. Here's my message, quoting the original one: https://facelets.dev.java.net/servlets/ReadMsg?list=users&msgNo=8882 And here's the bugzilla entry someone made for it: https://facelets.dev.java.net/issues/show_bug.cgi?id=260 And more importantly, From Mark message #2 The [D2D] FaceletViewHandler owns the DefaultFaceletFactory, so all users would be sharing the same cache of Facelet objects, since I believe all requests in an application share the same ViewHandler. But, what could explain the continuous leaking of HashMap entry objects, is if the Facelet refreshing is enabled. That's a mechanism typically used in development for rapid application development, and also in production to allow for changing content without having to restart the application. If it has a value of -1, then refreshing is disabled, and content is static, otherwise it's the number of seconds that a Facelet will be reused for, before reparsing it from the .xhtml file. The default value is 2. And 0 would effectively mean to always reparse. Small values like 2 are useful for debugging, but not production. Have them try -1, to see if the problem goes away. Afterwards they can tune it to whatever they like, if they want to be able to update pages on the go. <context-param> <param-name>facelets.REFRESH_PERIOD</param-name> <param-value>2</param-value> </context-param>

Greg Dick added a comment - 31/Jul/08 1:08 PM Customer tried the REFRESH_PERIOD fix, and it didn't help.

Mark Collette added a comment - 05/Jan/09 5:01 PM When this issue is fixed in Facelets, we'll incorporate it.