FreeMarker › freemarker-user

freemarker plus javarebel problems...caching?

21 messages

1 2

jonchase

freemarker plus javarebel problems...caching?

Reply Threaded

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-user

Attila Szegedi-3

Re: freemarker plus javarebel problems...caching?

Reply Threaded

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

ekabanov

Re: freemarker plus javarebel problems...caching?

Reply Threaded

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
FreeMarker-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freemarker-user

Attila Szegedi-3

Re: freemarker plus javarebel problems...caching?

Reply Threaded

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

jonchase

Re: freemarker plus javarebel problems...caching?

Reply Threaded

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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-user

ekabanov

Re: freemarker plus javarebel problems...caching?

Reply Threaded

In reply to this post by Attila Szegedi-3

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
FreeMarker-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freemarker-user

ekabanov

Re: freemarker plus javarebel problems...caching?

Reply Threaded

In reply to this post by jonchase

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 <szegedia@gmail.com> 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
> FreeMarker-user@lists.sourceforge.net
> 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
FreeMarker-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freemarker-user

Attila Szegedi-3

Re: freemarker plus javarebel problems...caching?

Reply Threaded

On 2008.05.15., at 12:20, ekabanov wrote:

>
> Sorry, no comments :)

No problem. I'm happy to take my kids out to park this afternoon to
throw frisbee instead of figuring out how to work around this in order
to enrich someone's experience with a proprietary product.

Cheers,
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-user

ekabanov

Re: freemarker plus javarebel problems...caching?

Reply Threaded

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. And the fix is very easy, just reset the cache when you don't find some property or method and retry once.

Cheers,
Jevgeni Kabanov

Attila Szegedi-3 wrote:

On 2008.05.15., at 12:20, ekabanov wrote:

>
> Sorry, no comments :)

No problem. I'm happy to take my kids out to park this afternoon to
throw frisbee instead of figuring out how to work around this in order
to enrich someone's experience with a proprietary product.

Cheers,
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
FreeMarker-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freemarker-user

jonchase

Re: freemarker plus javarebel problems...caching?

Reply Threaded

In reply to this post by Attila Szegedi-3

Attila,

I took your advice - I'm now creating a new BeanWrapper (DefaultObjectWrapper actually). I do this on every request, and I can't see a performance hit, so this will work fine for development (I'll turn it off in production).

Once I figured out how to get hold of the Configuration instance, it was as easy as:

configuration.setObjectWrapper(new DefaultObjectWrapper());

Thanks for the help!

Jon Chase

For posterity, here's the solution for Spring MVC I used:

public class DebuggingFreeMarkerClassReloaderInterceptor extends HandlerInterceptorAdapter {
    @Autowired
    FreeMarkerConfigurer freeMarkerConfigurer;
    /** Resets the ObjectWrapper before view is rendered - called on every request. */
    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
            ModelAndView modelAndView) throws Exception {
        freeMarkerConfigurer.getConfiguration().setObjectWrapper(new DefaultObjectWrapper());
    }
}

On Thu, May 15, 2008 at 6:44 AM, Attila Szegedi <[hidden email]> wrote:

On 2008.05.15., at 12:20, ekabanov wrote:

>
> Sorry, no comments :)

No problem. I'm happy to take my kids out to park this afternoon to
throw frisbee instead of figuring out how to work around this in order
to enrich someone's experience with a proprietary product.

Cheers,
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-user

Attila Szegedi-3

Re: freemarker plus javarebel problems...caching?

Reply Threaded

In reply to this post by ekabanov

On 2008.05.15., at 12:48, 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.

> And
> the fix is very easy, just reset the cache when you don't find some
> property
> or method and retry once.

I know we have users that write templates that rely on negative lookup
of properties. Making testing for absence of a property expensive (by
forcing reflective reinspection of the class) is something I'd not be
comfortable with... Making it easy to wire selective cache purging to
an event publishing mechanism in your API would be a better idea.

Or we could make the reinspection on failed property lookup a
configurable property on BeansWrapper - users can turn it on if they
use hotswapping and keep it turned off otherwise.

Attila.

> Cheers,
> Jevgeni Kabanov

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-user

Daniel Dekany

Re: freemarker plus javarebel problems...caching?

Reply Threaded

In reply to this post by ekabanov

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. It's not Ruby. HotSwap doesn't
violate this too much either, because you just change the behavior of
methods, which is of course possible even without HotSwap (and thus,
AFAIK, HotSwap doesn't confuse BeansWrapper). Besides, even HotSwap
can confuse a program, unless you are careful in what/when/with-what
do you HotSwap. Now if I understand well, JavaRebel can change the
"public interface" of classes... well, then it's granted that it will
break many 3rd party products. I'm not saying that it's not useful,
but that you have to know very well which classes can be re-loaded
without causing mess. Like, I can imagine that an MVC Action class and
like can be, but in no way it's something that you can do in general,
and then expecting 3rd party stuff to survive it. So, sorry, if there
is a wrong assumption there, then it's not on the side of FreeMarker
in this case (or on the side of any other projects that will be
confused). Saying that would be quite a business man talk.

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

> Cheers,
> Jevgeni Kabanov
>
>
> Attila Szegedi-3 wrote:
>>
>>
>> On 2008.05.15., at 12:20, ekabanov wrote:
>>
>>>
>>> Sorry, no comments :)
>>
>> No problem. I'm happy to take my kids out to park this afternoon to
>> throw frisbee instead of figuring out how to work around this in order
>> to enrich someone's experience with a proprietary product.
>>
>> Cheers,
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>>
>>
>

--
Best regards,
Daniel Dekany

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-user

Attila Szegedi-3

Re: freemarker plus javarebel problems...caching?

Reply Threaded

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-user

Jonathan Revusky-3

Re: freemarker plus javarebel problems...caching?

Reply Threaded

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?

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.

JR

On Fri, May 16, 2008 at 2:53 PM, Attila Szegedi <[hidden email]> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>

ekabanov

Re: freemarker plus javarebel problems...caching?

Reply Threaded

In reply to this post by Attila Szegedi-3

1) Class immutability is not required by the JVM spec. For example if you check out http://java.sun.com/j2se/1.5.0/docs/api/java/lang/instrument/Instrumentation.html#redefineClasses(java.lang.instrument.ClassDefinition[]) you can see, that "The redefinition must not add, remove or rename fields or methods, change the signatures of methods, or change inheritance. These restrictions maybe be lifted in future versions. " There is actually no place in JVM/Java specs that say class interfaces cannot change. In fact if you check out java1.6u10 it has some functionality to deal with the cases when the reflection results change, so you can hardly say that JavaRebel violates anything. It is just a common assumption that framework developers made before it was actually practically possible to redefine classes.

2) You can do both. You can let users call setAssumeMutableClasses(true) and we can set e.g. "javax.vm.reloadable=true" to let frameworks know that a reloading agent is running (wouldn't want to tie this to JavaRebel only). Will this work?

Sorry for the crappy reply style, Nabble sucks :(

Jevgeni Kabanov

Attila Szegedi-3 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
FreeMarker-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freemarker-user

jonchase

Re: freemarker plus javarebel problems...caching?

Reply Threaded

In reply to this post by Jonathan Revusky-3

On Fri, May 16, 2008 at 9:13 AM, Jonathan Revusky <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-user

Attila Szegedi-3

Re: freemarker plus javarebel problems...caching?

Reply Threaded

In reply to this post by ekabanov

Hey, Jevgeni -- I've had a bit of a time to look into this this
weekend. Technically, it seems trivial to add a class reload listener
to FreeMarker using JavaRebel's API.

I only have a question of legal nature: we host a copy of all our 3rd
party dependency JAR files on SourceForge in order to allow people to
compile FreeMarker without having them do their own jarfile hunt. Our
build.xml just pulls these from sf.net and compiles FreeMarker source
against them. Would you mind if we hosted javarebel.jar, or at least a
stripped down version of it with only those .class files we require
for compilation?

Attila.

On May 16, 2008, at 3:19 PM, ekabanov wrote:

>
> 1) Class immutability is not required by the JVM spec. For example
> if you
> check out
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/instrument/Instrumentation.html#redefineClasses(java.lang.instrument.ClassDefinition
> [])
> you can see, that "The redefinition must not add, remove or rename
> fields or
> methods, change the signatures of methods, or change inheritance.
> These
> restrictions maybe be lifted in future versions. " There is actually
> no
> place in JVM/Java specs that say class interfaces cannot change. In
> fact if
> you check out java1.6u10 it has some functionality to deal with the
> cases
> when the reflection results change, so you can hardly say that
> JavaRebel
> violates anything. It is just a common assumption that framework
> developers
> made before it was actually practically possible to redefine classes.
>
> 2) You can do both. You can let users call
> setAssumeMutableClasses(true) and
> we can set e.g. "javax.vm.reloadable=true" to let frameworks know
> that a
> reloading agent is running (wouldn't want to tie this to JavaRebel
> only).
> Will this work?
>
> Sorry for the crappy reply style, Nabble sucks :(
>
> Jevgeni Kabanov
>
>
> Attila Szegedi-3 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 the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
FreeMarker-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-user

ekabanov

Re: freemarker plus javarebel problems...caching?

Reply Threaded

Hi!

You don't need to compile against the javarebel.jar, specially for this reason we publish the JavaRebel SDK distribution including the javarebel-sdk.jar, which is open source under Apache License 2.0. You can get it from here:
http://zt-oss.googlecode.com/files/javarebel-sdk-1.2.zip

You are of course free to host it anywhere you please or redistribute it or whatever.

Jevgeni Kabanov

Attila Szegedi-3 wrote:

Hey, Jevgeni -- I've had a bit of a time to look into this this
weekend. Technically, it seems trivial to add a class reload listener
to FreeMarker using JavaRebel's API.

I only have a question of legal nature: we host a copy of all our 3rd
party dependency JAR files on SourceForge in order to allow people to
compile FreeMarker without having them do their own jarfile hunt. Our
build.xml just pulls these from sf.net and compiles FreeMarker source
against them. Would you mind if we hosted javarebel.jar, or at least a
stripped down version of it with only those .class files we require
for compilation?

Attila.

On May 16, 2008, at 3:19 PM, ekabanov wrote:

>
> 1) Class immutability is not required by the JVM spec. For example
> if you
> check out
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/instrument/Instrumentation.html#redefineClasses(java.lang.instrument.ClassDefinition
> [])
> you can see, that "The redefinition must not add, remove or rename
> fields or
> methods, change the signatures of methods, or change inheritance.
> These
> restrictions maybe be lifted in future versions. " There is actually
> no
> place in JVM/Java specs that say class interfaces cannot change. In
> fact if
> you check out java1.6u10 it has some functionality to deal with the
> cases
> when the reflection results change, so you can hardly say that
> JavaRebel
> violates anything. It is just a common assumption that framework
> developers
> made before it was actually practically possible to redefine classes.
>
> 2) You can do both. You can let users call
> setAssumeMutableClasses(true) and
> we can set e.g. "javax.vm.reloadable=true" to let frameworks know
> that a
> reloading agent is running (wouldn't want to tie this to JavaRebel
> only).
> Will this work?
>
> Sorry for the crappy reply style, Nabble sucks :(
>
> Jevgeni Kabanov
>
>
> Attila Szegedi-3 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 the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
FreeMarker-user mailing list
FreeMarker-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freemarker-user

ekabanov

Re: freemarker plus javarebel problems...caching?

Reply Threaded

In reply to this post by Attila Szegedi-3

Hi!

You don't need to compile against the javarebel.jar, specially for
this reason we publish the JavaRebel SDK distribution including the
javarebel-sdk.jar, which is open source under Apache License 2.0. You
can get it from here:
http://zt-oss.googlecode.com/files/javarebel-sdk-1.2.zip

You are of course free to host it anywhere you please or redistribute
it or whatever.

Jevgeni Kabanov

On Sun, Oct 19, 2008 at 4:52 PM, Attila Szegedi <[hidden email]> wrote:

> Hey, Jevgeni -- I've had a bit of a time to look into this this weekend.
> Technically, it seems trivial to add a class reload listener to FreeMarker
> using JavaRebel's API.
>
> I only have a question of legal nature: we host a copy of all our 3rd party
> dependency JAR files on SourceForge in order to allow people to compile
> FreeMarker without having them do their own jarfile hunt. Our build.xml just
> pulls these from sf.net and compiles FreeMarker source against them. Would
> you mind if we hosted javarebel.jar, or at least a stripped down version of
> it with only those .class files we require for compilation?
>
> Attila.
>
> On May 16, 2008, at 3:19 PM, ekabanov wrote:
>
>>
>> 1) Class immutability is not required by the JVM spec. For example if you
>> check out
>>
>> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/instrument/Instrumentation.html#redefineClasses(java.lang.instrument.ClassDefinition[])
>> you can see, that "The redefinition must not add, remove or rename fields
>> or
>> methods, change the signatures of methods, or change inheritance. These
>> restrictions maybe be lifted in future versions. " There is actually no
>> place in JVM/Java specs that say class interfaces cannot change. In fact
>> if
>> you check out java1.6u10 it has some functionality to deal with the cases
>> when the reflection results change, so you can hardly say that JavaRebel
>> violates anything. It is just a common assumption that framework
>> developers
>> made before it was actually practically possible to redefine classes.
>>
>> 2) You can do both. You can let users call setAssumeMutableClasses(true)
>> and
>> we can set e.g. "javax.vm.reloadable=true" to let frameworks know that a
>> reloading agent is running (wouldn't want to tie this to JavaRebel only).
>> Will this work?
>>
>> Sorry for the crappy reply style, Nabble sucks :(
>>
>> Jevgeni Kabanov
>>
>>
>> Attila Szegedi-3 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.
>
>
>
>
>

Attila Szegedi-3

Re: freemarker plus javarebel problems...caching?

Reply Threaded

Perfect!

Thanks,
Attila.

On Oct 19, 2008, at 5:17 PM, Jevgeni Kabanov wrote:

> Hi!
>
> You don't need to compile against the javarebel.jar, specially for
> this reason we publish the JavaRebel SDK distribution including the
> javarebel-sdk.jar, which is open source under Apache License 2.0. You
> can get it from here:
> http://zt-oss.googlecode.com/files/javarebel-sdk-1.2.zip
>
> You are of course free to host it anywhere you please or redistribute
> it or whatever.
>
> Jevgeni Kabanov
>
> On Sun, Oct 19, 2008 at 4:52 PM, Attila Szegedi <[hidden email]>
> wrote:
>> Hey, Jevgeni -- I've had a bit of a time to look into this this
>> weekend.
>> Technically, it seems trivial to add a class reload listener to
>> FreeMarker
>> using JavaRebel's API.
>>
>> I only have a question of legal nature: we host a copy of all our
>> 3rd party
>> dependency JAR files on SourceForge in order to allow people to
>> compile
>> FreeMarker without having them do their own jarfile hunt. Our
>> build.xml just
>> pulls these from sf.net and compiles FreeMarker source against
>> them. Would
>> you mind if we hosted javarebel.jar, or at least a stripped down
>> version of
>> it with only those .class files we require for compilation?
>>
>> Attila.
>>
>> On May 16, 2008, at 3:19 PM, ekabanov wrote:
>>
>>>
>>> 1) Class immutability is not required by the JVM spec. For example
>>> if you
>>> check out
>>>
>>> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/instrument/Instrumentation.html#redefineClasses(java.lang.instrument.ClassDefinition
>>> [])
>>> you can see, that "The redefinition must not add, remove or rename
>>> fields
>>> or
>>> methods, change the signatures of methods, or change inheritance.
>>> These
>>> restrictions maybe be lifted in future versions. " There is
>>> actually no
>>> place in JVM/Java specs that say class interfaces cannot change.
>>> In fact
>>> if
>>> you check out java1.6u10 it has some functionality to deal with
>>> the cases
>>> when the reflection results change, so you can hardly say that
>>> JavaRebel
>>> violates anything. It is just a common assumption that framework
>>> developers
>>> made before it was actually practically possible to redefine
>>> classes.
>>>
>>> 2) You can do both. You can let users call
>>> setAssumeMutableClasses(true)
>>> and
>>> we can set e.g. "javax.vm.reloadable=true" to let frameworks know
>>> that a
>>> reloading agent is running (wouldn't want to tie this to JavaRebel
>>> only).
>>> Will this work?
>>>
>>> Sorry for the crappy reply style, Nabble sucks :(
>>>
>>> Jevgeni Kabanov
>>>
>>>
>>> Attila Szegedi-3 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.

1 2