Re: freemarker plus javarebel problems...caching?

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