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: [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]
--
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]
