cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: ReloadingClassLoader
Date Thu, 22 Mar 2007 09:51:01 GMT
>>> And what configuration is necessary for production so that  
>>> classes are "only" instrumented?
>> For javaflow all you need is to use this store. For both -  
>> compiling or reloading. Of course it would be good to configure  
>> the packages that should be instrumented. I can add that to that  
>> store directly if you want.
>>  http://jakarta.apache.org/commons/sandbox/javaflow/apidocs/org/ 
>> apache/commons/javaflow/stores/JavaflowResourceStore.html
>
>
> sorry, I'm a confused. What do you mean by "this" and "that" store.  
> The current implementation is
>
> org.apache.commons.jci.listeners.ReloadingListener rl =
>     new CocoonReloadingListener();
> rl.addReloadNotificationListener(classloader);
> fam.addListener(directory, rl);
>
> and if I look into CocoonReloadingListener() which extends  
> org.apache.commons.jci.listeners.ReloadingListener I find that it  
> creates stores of type MemoryResourceStore.
>
> Am I right that, in order to support instrumentation for Javaflow,  
> I have to override the default behaviour and create stores of type  
> JavaflowResourceStore instead?

Correct! ...or we always use a javaflow store and work that out via  
configuration.

> This brings me to my other question: The cocoon-rcl-plugin is only  
> useful at development time. What options to instrument Javaflow  
> classes for production use do we have?

There is an ant task for it in javaflow atm, the maven-jci-compiler  
plugin will support that (but that's still a way to go) and we could  
write a quick and easy maven plugin for that. These are all options I  
see.

..or just use a FileResourceStore or serialize the  
MemoryResourceStore ;)

cheers
--
Torsten



Mime
View raw message