I tried JavaRebel today and for the most part it does what it says. It was really cool to see a single class updated in Tomcat without Tomcat reloading the application. However, there were a couple of gotchas that I am not sure how to overcome if possible at all.
1. For some reason a fellow developer where I work needed to get the package name of a class at runtime. So we have getClass().getPackage().getName(); Once JavaRebel is in place getPackage() returns null. Remove JavaRebel and it works fine. I assume this has something to do with a class wrapper.
2. I primarily use Stripes and one of the things Stripes tries to do is cache configuration information at startup. For example, to inject a Spring Bean into a Stripes ActionBean I simply provide an @SpringBean for a bean setter. If I decide to inject a new/different Spring Bean into the ActionBean, even though it already exists in the spring context, the class reloads but Stripes doesn't know about it. Is this a JavaRebel flaw? No, not really. As I said, it works as stated. But this does limit the effectiveness for me.
I still think it is slick and I am anxious to see how java development improves for us web developers as JavaRebel improves.
Monday, October 15, 2007
JavaRebel: Interesting but still iffy
Subscribe to:
Post Comments (Atom)
4 comments:
BTW, the first one is a known error and we are working on it.
The second is framework-specific problem, but we have some ideas for those as well.
Also the first problem has an easy workaround -- getClass().getName().substring(0, getClass().getName().lastIndexOf('.'));
(not to say that you should work around this, but until next release you can do that)
"Also the first problem has an easy workaround --"
Yea, that's what we've done.
"The second is framework-specific problem, but we have some ideas for those as well."
Which is why I said it wasn't a flaw in JavaRebel. But it does hinder its use.
We've fixed the getPackage() problem in the latest nightlies and upcoming 1.0 M3 build.
Post a Comment