cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Experimental per-sitemap reloadable classloader
Date Wed, 09 Mar 2005 10:44:11 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>  
>

<snip/>

>>This feature is intended for application development-time, as it doesn't 
>>take into consideration instances of the previous versions of the 
>>reloaded classes that may be stored here and there such as in session 
>>attributes. That means that you may get some ClassCastException whenever 
>>such a cases arises. This is the current price to pay for fast roundtrips.
>>
>>    
>>
>Great!!
>
>What about using this for blocks - a simple version - as well? So we
>could just drop a block of functionality (or a web app) into Cocoon. The
>sitemap has the includes for the components and this extra classpath.
>  
>

Yes, sure. That's how I started using it today with my mount-table 
mounted project! Here's a snippet of my sitemap:
    <map:components>
        <map:classpath>
            <class-dir src="BLOCK-INF/classes"/>
            <lib-dir src="BLOCK-INF/lib"/>
        </map:classpath>
        ...
    </map:components>

Real-block ready!!

>For reloading: when the sitemap is reloaded, the classloader could only
>reload those classes/jars that have changed since the last load/reload.
>  
>

Yes, but the classloader is created as part of the TreeProcessor build 
process and therefore it's an all or nothing operation. Smarter 
reloading would mean transmitting the classloader from the current 
processor to the newly created one, checking that the classpath 
definition hasn't changed and crawling the classpath in search for changes.

Not impossible, but a bit complicated and it won't fully solve the 
ClassCastException problem for session attributes instance of reloaded 
classes, although it will reduce the associated annoyances by reducing 
the number of reloaded classes.

Problem also is that keeping unchanged classes means keeping their 
classloader and that therefore we need the classloader for reloaded 
class to be a child of the previous one, thus creating a classloader 
chain that will grow over time. Maybe that will impact memory and 
performance.

Hmm... need more thinking ;-)

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message