One of the main reasons for using Ruby instead of Tapestry is the short and quick development cycle. ruby: save + browse java: save + restart + init app + click through your app pages to get to the page before restart
(visionary-mode = on) having a reload-capable classloader could eventually reduce the development cycle to a ruby-style one. just because other people didn't do it does not mean it's not possible. having a quick development cycle could also attract a huge group of people to use tapestry (instead of heavyweights like jsf) what you guys think? is it possible? having any great ideas? -----Ursprüngliche Nachricht----- Von: Hensley, Richard [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 6. Oktober 2005 19:34 An: Tapestry users Betreff: RE: OutOfMemoryError Tapestry 4.0 Playing with class loaders in Java is kind like playing with fire with only a small bucket of water around. You can do it, but you will eventually get burnt. It would significantly change the semantics of how Tapestry currently works because class loaders are also namespace boundaries within java. As soon as you create a class loader, it can only access instances of classes within it's self of within it's parentage. So, if you create a discardable class loader, how would you implement methods like IRequestCycle.getPage() and make it compatible with a discardable class loader. Not an easy problem. Considering the pain in development mode is that you have to restart your server occasionally, I'm not convinced capsizing the boat would be worth it. Richard -----Original Message----- From: Peter Ertl [mailto:[EMAIL PROTECTED] Sent: Thursday, October 06, 2005 10:28 AM To: Tapestry users Subject: RE: OutOfMemoryError Tapestry 4.0 <naive question> wouldn't it be a good thing to use a discardable class loader in dev-mode? </naive question> > --- Ursprüngliche Nachricht --- > Von: "Hensley, Richard" <[EMAIL PROTECTED]> > An: "Tapestry users" <tapestry-user@jakarta.apache.org> > Betreff: RE: OutOfMemoryError Tapestry 4.0 > Datum: Thu, 6 Oct 2005 13:24:19 -0400 > > 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] > --------------------------------------------------------------------- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
