Of course I've been thinking along those lines. Java does get in the way, however. ClassLoaders are tricky, tricky things.
On 10/6/05, Peter Ertl <[EMAIL PROTECTED]> wrote: > 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] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
