Using JRebel 3 with JSF 2, Weld 1.0, EJB 3.0

[asookazian]

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

[swd847]

Until some writes a JRebel plugin for weld you will get limited usefulness from the plugin. Even if JRebel can reload the EJB's, you would also need to re-create the  weld metadata for them.

Jboss 5+ changed the server layout, the jars are in common/lib now so they are not duplicated.

On a related note I have started working on a class reloading solution that I hope to release as open source in the near future. It only allows add/removing of static methods and changing annotation data at the moment but I think the concept is sound.

[diegocoronel]

i have a similar environment running in my home.

Im using: Glassfish V3, Weld, JSF2, Flex, GraniteDS, JPA2, Eclipse, JRebel and Lombok.

I can say that its a really interesting environment, JRebel works really nice (im not using EJB) and of course it just dont reload metadata.. but i always lost time creating/editing methods to my interface logic and now i have it improved... its rare i need to restart my server. Even if its necessary glassfish starts in 9 seconds.

I think JEE6 is the best release i can see for 2010.

Sry about english. :)

[asookazian]

Stuart Douglas wrote on Feb 09, 2010 23:19:


It only allows add/removing of static methods and changing annotation data at the moment but I think the concept is sound.

Please elaborate.  Sounds somewhat similar to what JRebel 3 is doing in terms of adding/removing EJB 3.0 methods.  Will yours achieve this as well?

For static methods and changing annotation data,  plz provide some example scenarios.  thx.

[asookazian]

Diego Coronel wrote on Feb 09, 2010 23:41:


i have a similar environment running in my home.

Im using: Glassfish V3, Weld, JSF2, Flex, GraniteDS, JPA2, Eclipse, JRebel and Lombok.

I can say that its a really interesting environment, JRebel works really nice (im not using EJB) and of course it just dont reload metadata.. but i always lost time creating/editing methods to my interface logic and now i have it improved... its rare i need to restart my server. Even if its necessary glassfish starts in 9 seconds.

I think JEE6 is the best release i can see for 2010.

Sry about english. :)

Interesting stack.  Not familiar with Lombok but I just saw their website and it looks like a smaller open-source project with custom annotations.

How/when do you use JSF2 (facelets) vs. Flex or do you use both on the same pages?

Are you planning to use Seam3 in the future?

[swd847]

Please elaborate.  Sounds somewhat similar to what JRebel 3 is doing in terms of adding/removing EJB 3.0 methods.  Will yours achieve this as well?

For static methods and changing annotation data,  plz provide some example scenarios.  thx.

Basically as classes are loaded into the VM they have a static method added to them with a generic signature:

Object ___new_static_method_(int functionNo, Object[] args)
{
   return null;
}

if you then try and add a method to the class at a later point this method is removed from the class definition and the code is placed inside this new method (inside an if statement depending on functionNo). As classes are loaded into the JVM that refer to the new method they are re-written to call this method instead.

Some calls to the reflection API are also replaced. e.g. Class.getMethods() is replaced with a call to the static method ReflectionImpl.getMethods(Class). This method will return any added methods as well as the existing ones.

This explanation has been simplified somewhat, but it should be enough to get the general idea. I belive JRebel does something similar, although I have not used it I can't see any other way it could work (you can't actually hot replace classes, its impossible).

[asookazian]

Why are you seemingly trying to reinvent the wheel?  Is there some advantage(s) to your design/solution over JRebel?  Will yours incrementally hot deploy changes to EJB 3.x components?  JRebel is claiming interface change (e.g. add/delete method) hot deploy for EJB 3.0 components.

This is how JRebel works:

How does JRebel work?

JRebel integrates with the JVM and application servers mainly on the class loader level. It does not create any new class loaders, instead, it extends the existing ones with the ability to manage reloaded classes.

When a class is loaded JRebel will try to find a corresponding .class file for it. It will search from the classpath (including an application classpath, like WEB-INF/classes) and from the places specified in the rebel.xml configuration file. If it find a .class file JRebel instruments the loaded class and associates it with the found .class file. The .class file timestamp is then monitored for changes in the loaded class and updates are propagated through the extended class loader, to your application.
JRebel can also monitor .class files in JARs if they are specified in rebel.xml.

Importantly, when loading updates to a class, JRebel preserves all of the existing instances of that class. This allows the application to just continue working, but also means that when adding a new instance field it will not be initialized in the existing instances, since the constructor will not be rerun.

http://www.zeroturnaround.com/jrebel/faq/#What_is_jrebel

Configuring JARs

JARs are usually not deployed on their own, but as a part of application (e.g. WEB-INF/lib in WARs or EJB modules in EARs). However often you still want to update their code on-the-fly. Let’s assume that we have a module my-business-module.jar deployed in WEB-INF/lib. You can propagate the changes from your workspace by adding the following rebel.xml to the root of the JAR file:

<?xml version="1.0" encoding="UTF-8"?>
<application
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns="http://www.zeroturnaround.com"
  xsi:schemaLocation="http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
  <classpath>
    <dir name="c:\myWorkspace\myBusinessModule\target\classes"/>
    <dir name="c:\myWorkspace\myBusinessModule\src\main\resources"/>
  </classpath>
</application>

This will mount classes and resources in directories c:\myWorkspace\myBusinessModule\target\classes and c:\myWorkspace\myBusinessModule\src\main\resources before the classes and resources in the JAR file. Changes to those classes and resources will propagate to the application.

http://www.zeroturnaround.com/jrebel/how-to-configure-rebel-xml/

There are some very interesting articles that Yevgeny has made available recently:

http://www.zeroturnaround.com/blog/reloading_java_classes_401_hotswap_jrebel/

http://www.zeroturnaround.com/blog/rjc301/

[swd847]

The big difference will be that my one will be open source.

That quote you posted about how JRebel works is a bit of a red herring. All that tells you is that it monitors class files for changes, which is not really the difficult part.

With regard to redeploying EJB's etc this requires integration with the framework/container. Open source projects are probably more likely to spend time writing integration code for another open source solution that for a proprietary one. Also once it matures it would open up the possibility of having 'out of the box' hot reloading for some frameworks as they could just bundle it.

[asookazian]

Well they sighted this VM arg in the first email I got from them: -Drebel.jboss_plugin=true

so there must be some level of integration going on.

anyways, I wonder how .NET/CLR is handling incremental hot deployment or RoR/Grails?  If there exists a platform where all files are incrementally hot-deployable, I'd be very impressed.  In my last 11 years in software development (client/server or web technologies), I've never worked in an envmt that was 100% hot deploy friendly from a development sense, not production, of course...

Perhaps the JVM and the classloader mechanism is the root cause here...

[asookazian]

Here are some new updates from zeroturnaround support:

If you wish to debug while using jrebel then you should install our eclipse plugin http://www.zeroturnaround.com/update-site/ Otherwise breakpoints may not always hit and you'll get warnings about missing symbols and hotswap failures.
Invoking a new ejb method from a facelet is a rather complex thing. In your later email you mentioned that you got something working, but if this case still fails for you then you either forgot to add the method to ejb interface or we failed to clear jboss-el cache. In the second case it would be interesting to know your seam and jboss-el versions so we could investigate further.

Nice to hear that you succeeded in adding a new ejb method. We'll probably release M2 next week. If all goes well adding new @EJB and some seam annotations should also work. If you wish to play with it some more we can send you a 30day eval license and let you konw when the @EJB stuff reaches the nightly build.

So what do the JBoss guys think about this class reload tool?  Any problems you see with using it in Seam or Weld apps?

I'm hoping that all annotations will be incrementally reloadable as well in EJB 3.x components...

[asookazian]

Well I tried JRebel with translator app as well and the EJB hot reload did not work.

It does not work with the Seam 2.1.1.GA booking app running on 4.2.2.GA AS either!  buzzkill..........................

I'm getting:

14:52:00,315 ERROR [[Faces Servlet]] Servlet.service() for servlet Faces Servlet threw exception
javax.el.MethodNotFoundException: /main.xhtml @42,71 action="#{hotelSearch.party}": Method not found: HotelSearchingAction:4si4k5i-igycax-g5k58sv3-1-g5k59cm1-h.party()

But I know for sure it's not a method signature mismatch, etc. b/c the method does get invoked successfully from my new commandButton on the facelet if I save changes then build/deploy to JBoss 4.2.2.GA.

Awaiting response from zeroturnaround support...

this is an interesting RFE for the Sun JVM (top 25): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4910812

[swd847]

Have you tries on jboss 5?

The ejb integration might be tied to a specific version of jboss EJB3.

[asookazian]

No I haven't and I'm sort of getting tired of trying and hoping, etc.

Anyways, these two references/articles are interesting/helpful:

http://www.zeroturnaround.com/reference-manual/app.html#app-2.1

JRebel does not take such an approach. Instead it uses a much more complicated approach, based on advanced compilation techniques, that leaves us with one master class and several anonymous support classes backed by the JIT transformation runtime that allow modifications to take place without any visible degradation in performance or compatibility. It also

    - Leaves as many method invocations intact as possible. This means that JRebel minimizes its performance overhead, making it lightweight.
    - Avoids instrumenting the Java SDK except in a few places that are necessary to preserve compatibility.
    - Tweaks the results of the Reflection API, so that we can correctly include the added/removed members in these results. This also means that the changes to Annotations are visible to the application.

http://www.zeroturnaround.com/blog/reloading_java_classes_401_hotswap_jrebel/

Currently I'm trying to understand if you have an EAR, then must you have three rebel.xml files embedded in that EAR or is only one sufficient if you only need JRebel to monitor changes to the EJB classes in a particular JAR...

I have been trying the latter only.

I am seeing the following the console (which is good):

2010-02-11 14:51:18,705 INFO  [STDOUT] JRebel: Directory 'C:\java\jboss-seam-2.1.1.GA\examples\booking\exploded-archives\jboss-seam-booking.jar\org\jboss\seam\example\booking' will be monitored for changes.

Which is the result of this config in the rebel.xml:

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.zeroturnaround.com" xsi:schemaLocation="http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">

     <classpath>
          <dir name="C:/java/jboss-seam-2.1.1.GA/examples/booking/exploded-archives/jboss-seam-booking.jar/org/jboss/seam/example/booking">
          </dir>
     </classpath>

</application>

I also tried this (which was generated by the Eclipse plugin) which fails as well:

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.zeroturnaround.com" xsi:schemaLocation="http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">

     <classpath>
          <dir name="C:/java/jboss-seam-2.1.1.GA/examples/booking/exploded-archives/jboss-seam-booking.jar">
          </dir>
     </classpath>

</application>

I also posed the following question to their support team:

what happens when you start the Sun JVM in debug mode (i.e. HotSwap is available/working) and JRebel is instrumented as well via -javaagent:C:\temp\jrebel.jar, does JRebel take precedence on method body changes or what?

[asookazian]

Stuart Douglas wrote on Feb 12, 2010 00:06:

The ejb integration might be tied to a specific version of jboss EJB3.

Good point.  I just asked them.  If it's JBoss 5, nobody told me and it's not documented in a readme.txt, etc.  Also, I noticed that there is no datetime stamps in the logging in the rebel.log.  thx.

nothing in the changelog in the distro regarding EJB hot reload for 3.0:

********************************************
  JavaRebel Changelog                    
********************************************
3.0 M1 (15th October)
* Support for adding static fields and changing enums.
* Full JSP support (including accessing new methods, classes and fields from scriptlets)
* 25%-30% improvement on instrumented class memory use.
* JRebel no longer keeps references to classloaders after application redeployment.

Hopefully the forgot to add it???

[asookazian]

from zeroturnaround sppt:

I think we had a bug in the nightly build yesterday that caused all the classes to be read from the packaged archive instead of the directories used by rebel.xml. Download the nightly again and give it a try.

We'll probably release M2 next week. If all goes well adding new @EJB and some seam annotations should also work.

I have run tests with 4.0.5ga, 4.2.3ga, 5.0.1ga, 5.1.0ga and 6.0m1.

I will eventually be interested in all EE5/EE6 annotations working (i.e. hot reloading)...