Re: freemarker plus javarebel problems...caching?

On Fri, May 16, 2008 at 9:13 AM, Jonathan Revusky <[email protected]> wrote:

> Well, speed is not really an issue here, is it? I assume that the
> point of JavaRebel is to speed up the development process, isn't it?


Right, I don't think it's intended to be used in a production environment.


>
>
> If it's primarily for development/testing, why not just start the
> universe again on each request, instantiate a new Configuration
> object, with new TemplateLoaders and ObjectWrappers each time and it's
> probably still fairly fast just for testing, as opposed to re-
> starting an application server.


As I said in a previous post, "starting the universe again" worked for me.
A call to configuration.setObjectWrapper(new DefaultObjectWrapper()); on
each request seemed to do the trick for me.  I've noticed no performance
impact from the change *in development*.

I'm not involved in the FM development, but it seems to me that introducing
a config param (and the corresponding code modifications) to essentially
tell FreeMarker that the JVM it is running in adheres to the JLS blurs the
lines of FM's core concerns.

Jon Chase


>
>
> JR
>
>
>
> On Fri, May 16, 2008 at 2:53 PM, Attila Szegedi <[email protected]>
> wrote:
> >
> > On 2008.05.16., at 12:53, Daniel Dekany wrote:
> >
> >> Thursday, May 15, 2008, 12:48:11 PM, ekabanov wrote:
> >>
> >>> Well, it's not the only product that allows HotSwap -- IBM J9 has
> >>> some
> >>> support and Weblogic 10.3 features something called FastSwap. By
> >>> making
> >>> wrong assumptions you are just hurting your own users in the long
> >>> run.
> >>
> >> I'm pretty much sure that BeansWrapper didn't made a wrong assumption
> >> here.
> >> It's JavaRebel that breaks a contract of the Java platform. Most
> >> Java code will assume that the classes are immutable; this is just a
> >> basic thing in the Java philosophy.
> >
> > Not just in philosophy - class object immutability is required by the
> > JVM specification. What JavaRebel does is installs a native agent
> > library into the JVM, which results in pretty much custom,
> > implementation specific behavior arising during JVM operation, and is
> > actually inconsistent with JVM specification. FreeMarker does assume
> > it runs on JVM. JavaRebel makes the JVM it is loaded in break the JVM
> > spec, so it's strictly speaking no longer a *Java* VM anymore, and it
> > shows.
> >
> >>> And the fix is very easy, just reset the cache when you don't find
> >>> some property or method and retry once.
> >>
> >> If it's easy to fix it, then sure, why not... but I guess it's not
> >> easy, since there are some priority rules to resolve ambiguities, like
> >> to resolve method overloading ambiguities, Map VS Bean property
> >> ambiguities, etc. Anyway, Attila knows this better than me, he will
> >> tell...
> >
> > Well, if we just ditch the cached info for the class, it might start
> > working for previously nonexisting properties. However, we sometimes
> > do caching on wrapper instance level too - i.e. we create a
> > SimpleMethodModel or OverloadedMethodModel that is bound to an
> > instance. A change in method signatures could invalidate these in a
> > hard-to-debug ways, and since we aren't tracking  all wrapper
> > instances we create, we can't just reach in and patch them up.
> >
> > We *could* add a assumeMutableClasses property to BeansWrapper, so
> > when someone runs under JavaRebel he could call
> > setAssumeMutableClasses(true). Actually -- if JavaRebel were to define
> > some system property we can detect, we could do it automatically.
> >
> > Attila.
> >
> >
> > -------------------------------------------------------------------------
> > 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
>

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