users@jersey.java.net

Re: [Jersey] RAD hacking of Jersey apps with JRebel...

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 17 Mar 2010 10:39:59 +0100

Hi James,

Having had a quick look at the JavaDoc i believe it should be possible
to plugin in similar to what was mentioned in the blog entry.

 From the link you send on the forum a developer states:

   "but to implement ReloadListener requires having javarebel included
for the project, which I do not intend to do. "

I do not see how this can be avoided in some sense, since Jersey needs
to be notified when JavaRebel detects changes. This seems to be more
of an implementation detail.

If there was a jersey-java-rebel module this would isolate things
appropriately and we might be able to declare the ContainerNotifier in
the META-INF/services, although i am not totally sure about that.

The ContainerNotifier approach is currently a brute force approach
since it reloads the complete app, it is not smart enough to handle
removal, changes and additions to individual classes, which is
generally a hard problem to solve. Specific cases, such as addition
and removal of resource classes might be possible but requires a more
fine-grained interface and more thought into the synchronization
aspects of a cache (provider-based classes would be much harder to
support in this manner and a reload would be much easier in this
respect). But this is all a performance issue and if reload is fast
enough then i suppose it is not an issue.

One problem i observe with the current JavaRebel interface is a lack
of a change group, since i presume JavaRebel may detect more than one
change within a given time-frame. Jersey will reload for every change.

Also JAXB has the same issue, it caches stuff. Thus a complete
reloading will be necessary unless we put some logic in Jersey to
detect changes to JAXB stuff, which starts to get even more complex.

Paul.



On Mar 15, 2010, at 12:55 PM, James Strachan wrote:

> Using JRebel on a web app can really boost your edit code <-> reload
> browser response cycle. Basically it allows classes to be reloaded in
> the JVM in place. Its great when hacking, say, Lift apps; you can run
> your application like this in maven...
>
> export MAVEN_OPTS="-noverify -javaagent:$JAVAREBEL_HOME/
> javarebel.jar"
> mvn jetty:run
>
> where JAVAREBEL_HOME points to where you installed the jrebel jar -
> you can download it here:
> http://www.zeroturnaround.com/blog/free-javarebel-for-scala-users-zeroturnaround-announces/
>
>
> Then in another shell you can run
>
> mvn scala:cc
>
> Then as you write or edit Scala classes in your IDE/editor, the
> "scala:cc" incrementally compiles them to classes. Then the JRebel
> ninja stuff automatically reloads the classes inside the JVM. What
> this means is that you can hack Lift controllers and snippets of code
> - and just hit reload in your browser within about a second of the
> time you've finished editing and hey presto, you get to test your new
> code. No need to stop/start your web container etc. Very Railsish
>
> The above should work just as well with Glassfish too - or indeed any
> servlet container.
>
> This works great for things like Lift; however there's currently a bit
> of an issue for folks hacking Jersey apps; namely that adding a new
> Jersey controller - or updating a controller to add/remove/change the
> URI mappings; does not cause the re-loading of the Jersey URI mapping
> stuff - since right now (naturally) that just happens once on startup.
>
>
> All that is required really is a JRebel plugin for Jersey; which
> basically is a little listener to the JRebel events (such as when a
> class has been reloaded) which can then be used as a hook to
> re-initialise the Jersey filter/servlet to detect changes in the JAXRS
> mappings.
>
> This certainly isn't a show stopper or anything; its just a velocity
> thing; if folks could add new Scala/Java controllers on the fly
> without restarting their web app (whether Jetty, Glassfish, Tomcat,
> whatever) it'd help folks feel more RAD in a Railsy kinda way.
>
> I've raised an issue to track this so we don't forget about it.
> https://jersey.dev.java.net/issues/show_bug.cgi?id=486
>
>
> BTW this issue came up on the JRebel forum too
> http://www.zeroturnaround.com/forum/topic.php?id=330#post-1379
>
> here's a little article that shows how to implement a JRebel plugin...
> http://code.google.com/p/zt-oss/wiki/SimpleJavaRebelPlugin
>
> so basically if we had a little Jersey-JRebel plugin, folks could use
> it when they run their app inside Jersey/Tomcat/Glassfish, which would
> just listen for JRebel events that a class has been reloaded and
> decide if it might be a resource or not (e.g. has it any JAXRS
> annotations or is it a type currently used in the JAXRS URI space) and
> if so, reload the jersey filter/servlet stuff.
>
> Here's the SDK javadoc...
> http://www.zeroturnaround.com/docs/javarebel-sdk/javadoc/
>
> e.g. here's how to add a listener to be notified when a class was
> reloaded...
> http://www.zeroturnaround.com/docs/javarebel-sdk/javadoc/org/zeroturnaround/javarebel/Reloader.html
>
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>