Re: freemarker plus javarebel problems...caching?

Sorry, no comments :) The important part is that class identity does not
change.

Jevgeni Kabanov


jonchase wrote:
> 
> My guess is that JavaRebel is using a proxy in front of the real classes.
> Most likely when an underlying class changes, JavaRebel detects the change
> and reloads it, but the JavaRebel proxy (which is what FreeMarker is
> holding
> a reference to) remains the same.
> 
> Does that sounds right, Jevgeni?
> 
> Jon
> 
> On Thu, May 15, 2008 at 5:28 AM, Attila Szegedi <[email protected]>
> 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
>>
> 
> -------------------------------------------------------------------------
> 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--tp17238997p17250089.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/