Re: freemarker plus javarebel problems...caching?

It's a bad idea to rely on class identity changing, since it only will change
with a new classloader. Since JavaRebel preserves the class identity the
notion of detecting reloading breaks. Could you just reset caches and retry
getting the property after an exception? That's what we did with commons-el:
http://zt-oss.googlecode.com/files/commons-el-1.0-zt-patch.txt.

Jevgeni Kabanov


Attila Szegedi-3 wrote:
> 
> It does caching, and you wouldn't want to turn it off, because that'd  
> force class introspection on each access, and it'd kill performance.
> 
> The class introspection is managed by BeansWrapper, in  
> introspectClass() method. It has means to detect reloaded classes;  
> namely if it sees a class that has the same name as an already cached  
> one, but its identity is different, it will clear the cache. It will  
> also log an INFO message in the "freemarker.beans" log category saying  
> "Detected a reloaded class [com.mycompany.SomeClass]. Clearing  
> BeansWrapper caches."
> 
> And anyway, our introspection cache data is bound to Class object  
> identity, not its name (the name is just used as a check to detect  
> class reloading). When you reload classes, the newly loaded Class  
> objects have different identity, and will thus be inspected separately.
> 
> So, in a nutshell, it should be able to detect that class reloading  
> happened, and should clear its cache when it does... If you can afford  
> to do some debugging in BeansWrapper.introspectClassInternal(), you  
> could maybe spot what's wrong. I.e. when you reload classes, only  
> newly created instances of the class will be of the reloaded class -  
> already existing object instances will remain of their original, old  
> class; maybe you're still holding references to your old objects?
> 
> As an alternative workaround, you could just create a new instance of  
> BeansWrapper whenever you yourself detect class reloading, and pass it  
> to Configuration.setObjectWrapper(). That way the newly created  
> BeansWrapper will have no caches and will set out to introspect all  
> classes anew. But that really shouldn't be necessary -- as I said, we  
> did anticipate class reloading in FreeMarker (and anyway, we cache  
> based on identity of Class objects, not their name).
> 
> Attila.
> 
> --
> home: http://www.szegedi.org
> weblog: http://constc.blogspot.com
> 
> On 2008.05.14., at 21:26, Jonathan Chase wrote:
> 
>> I'm trying to use JavaRebel (http://www.zeroturnaround.com/ 
>> javarebel/) in my Spring MVC app...everything in pretty vanilla, and  
>> JavaRebel is correctly reloading class file changes.
>>
>> However, I've noticed that when I add a new method to a class,  
>> FreeMarker doesn't find it (until I restart the JVM).
>>
>> Is FreeMarker doing some sort of caching of class metadata?  If so,  
>> is there a way to turn that off so that it will pick up the changes  
>> in the class files?
>>
>> Thanks!
>> Jon
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> FreeMarker-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user
> 
> 

-- 
View this message in context: http://www.nabble.com/freemarker-plus-javarebel-problems...caching--tp17238997p17247102.html
Sent from the freemarker-user mailing list archive at Nabble.com.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/