Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <422EA160.5070601@apache.org>
Date: Wed, 09 Mar 2005 08:10:24 +0100
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Experimental per-sitemap reloadable classloader
References: <422E2C9E.9090608@apache.org> <422E3D12.7010505@apache.org>
In-Reply-To: <422E3D12.7010505@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Torsten Curdt wrote:

>> A side benefit, tremedously useful, is that the classloader is 
>> re-created when the sitemap is reloaded. So this allows, by setting a 
>> class-dir, to reload changed classes simply by touching the sitemap.
>
>
> Awesome, mate! :-D
>
> If we integrate the file alteration monitor from
> jci we can even trigger the sitemap reload
> without the need of touching the sitemap.
>
> ...and we could also hook in the byte code
> transformations (if needed ..like for javaflow)
>
> Do you think that would work?


The classloader is created by a factory that is looked up using 
o.a.c.Core.ClassLoaderFactory, given the <map:classpath> configuration 
object (see in src/java/core). So by defining this component in the root 
cocoon.xconf, we can plug in any classloader strategy we want.

What's missing however, is the notification link between the classloader 
and the sitemap engine, in order to trigger reloading. That's something 
that should be fairly easy to add.

>> Maybe not as smart as an automatic compiling classloader, but as saving 
>
>
> ...not sure if it really has to be a compiling classloader
> as long as we have a automated reloading from within the ide.


Yep, you're right. It only has a drawback for the vi or emacs addicts ;-)

>> 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.
>
>
> I think that's ok for development!


Overnight (the brain is a non-stop machine) I found a scheme that could 
avoid this session-attribute annoyance: we can automatically invalidate 
sessions that have been created before the classloader creation. When a 
local classloader is created somewhere within Cocoon, a timestamp is 
stored in a global Context attribute. When a request comes in, we 
invalidate the session (if it exists) if it was created before the last 
classloader creation. HttpSession.getCreationTime() gives us the 
necessary information for this.

> Great stuff!


Thanks! Not that complicated though: I added the handling of <classpath> 
in CoreServiceManager and reused some parts of the paranoid block. A 
2-hours hacking session to save a lot of time :-)

Sylvain

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