Re: freemarker plus javarebel problems...caching?

How on earth can it preserve the identity of the Class object yet  
change it? Once you call defineClass(), it's immutable.

Attila.

On 2008.05.15., at 8:54, ekabanov wrote:

>
> 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/