I have been notified by the zeroturnaround support team that a new version of the JRebel plugin is available for testing. Here is the email thread:
We have implemented adding new methods to ejb interfaces on jboss in nightly builds. You can donwload the nightly build from http://www.zeroturnaround.com/nightly-build/jrebel-nightly-dev.zip
also add -Drebel.jboss_plugin=true -Drebel.allow_bytecode_proxy=true to jvm arguments. We would be interested to know how well it works on a real project and what more we could do to make jrebel work better with seam.
EJB 3.1 is not supported by any of the released jboss versions so we just have to wait while the jboss guys implement it and see if we need to do any special integration.
About using jrebel with seam/ejb/jsf/weld we don't have any special instructions. Jrebel core functionality (reloading classes) should work nicely but functionality that requires integration with the specific container/framework (such as adding a new @EJB field) may be missing and that's where we would need user feedback to know what features users really miss.
So I have been testing with out existing Seam 2.1.1.GA app at work with this new version of JRebel and so far have not been able to hot deploy a local interface method addition and corresponding class impl method addition. The method invocation on the Seam component fails because the method is not found.
Anyways, I'm wondering if I would be able to use the following combination of technologies:
JBoss 6.0.0.M1, JRebel 3.0-M2-SNAPSHOT, JSF 2.0 (Mojarra), Weld 1.0.x, EJB 3.0.
Do the EJB JARs ship with JBoss 6? The server/default/lib is empty in AS 6, it's not empty in AS 4.2 (and some EJB JARs are located in there).
Anyways, bottom line: is it possible to hot deploy EJBs in a JSF2/Weld app in JBoss 6 now??
btw, I'm not too happy about not being able to hot deploy bijection and @DataModel or @EJB. But this is a very good first step (assuming I'm making some config mistakes!) towards EJB higher-level dev productivity. I'm also wondering how it will behave with EJB 3.1 and optional local interfaces...