Re: freemarker plus javarebel problems...caching?

Obviously not. For a start JVM HotSwap allows to change class bytecode and
preserve class identity, it's just limited to method bodies. JavaRebel
isn't. How exactly we do it is a commercial secret.

Jevgeni Kabanov


Attila Szegedi-3 wrote:
> 
> 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/
> _______________________________________________
> 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--tp17238997p17250050.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/