Generated Classes are loaded into a class loader so they can be instantiated by Tapestry and Hivemind. The only way to release the generated classes is to release the class loader.
I tried once to evict classes from a ClassLoader while I was doing some Groovy stuff, according to the ClassLoader specification, it's not possible to evict a class. After you think about it for a while, you come to the conclusion that this is a good thing. I think that Hivemind and Tapestry load the generated classes into the same class loader that owns the parent class of the generated class. This class loader can not be released because it is owned by the application container. So, the real question is why are some many classes being generated. The flag noted by Howard below causes a class to be generated each time a page with abstract properties is visited. When running in production, my experience is that the classes only get generated the first time they are needed. So, the next avenue of investigation is to figure out what the actual generated classes are that were being reported as part of CtClass by the memory leak tool. Richard -----Original Message----- From: Leonardo Quijano Vincenzi [mailto:[EMAIL PROTECTED] Sent: Thursday, October 06, 2005 10:10 AM To: Tapestry users Subject: Re: OutOfMemoryError Tapestry 4.0 Howard Lewis Ship escribió: >That might be reasonable if you are running with >-Dorg.apache.tapestry.disable-caching=true > >With caching disabled, Tapestry has to constantly create new enhanced >subclasses for every page and every component. > > Shouldn't it delete old classes? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
