I had some success with an approach like you describe in an old
system where I was doing runtime code generation and compilation (nothing
too sophisticated, I was manually writing legal source and compiling it at
runtime to create fast stub class and avoid reflection). Basically I just
threw away the entire classloader anytime I had to rebuild a class and
forced hard reloads of *all* my generated classes.
If I recall I had to put in place some uber-strict rules about class
access though e.g. my stub classes *only* came out of a factory so I could
take control of the class loading myself.
The system in question never saw the light of day (reflection got
faster and struck everyone involved as safer), so there might have been some
hidden gotchas that would show up under load (like what happens in thread A
has an active copy of class foo, but we've now moved on to fooPrime and
thread B asks for an instance... icky...)
For single user single threaded it worked though if I recall.
--- Pat
> -----Original Message-----
> From: Peter Ertl [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 06, 2005 4:06 PM
> To: tapestry-user@jakarta.apache.org
> Subject: Re: OutOfMemoryError Tapestry 4.0
>
> Could some artificial restrictions on the pages, components, beans
> whatever
> lower the natural java + vm limits that eventually reload is possible?
>
> As far I get it the problems are mainly due to a missing clean separation
> between the core system classes that stay resident and the application
> part
> that should be reloaded.
>
> I could imagine that establishing an immutable demarcation line of
> interfaces
> between system and app might be an approach. additionally, within the app
> enforcing
> the use of a custom class loader that is reload-capable.
>
> (thinking loudly, please excuse if that was just b.s. :-)
>
>
> On Fri, 07 Oct 2005 00:36:55 +0200, Howard Lewis Ship <[EMAIL PROTECTED]>
> wrote:
>
> > 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: tapestry-user-
> [EMAIL PROTECTED]
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: tapestry-user-
> [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]
> >
>
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
> ---------------------------------------------------------------------
> 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]
