On 17 March 2010 09:39, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> 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.
Yeah; I was hoping we could go the META-INF/services route so that you
could put the jersey-jrebel moduel in your glassfish/jersey plugin in
maven; adding it to the classpath when you run your app in
glassfish/jersey/whatever - yet your app and your WAR stays free from
JRebel. (BTW its renamed from JavaRebel to JRebel - I guess due to
trademark issues).
> 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.
Though still, doing the brute force reload is going to be much quicker
than killing and restarting maven + glassfish/jersey/whatever. We can
always add a more clever updater later on.
> 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.
Yeah. For now I'd be totally happy with a complete reload, as its
usually pretty fast. For me its much faster than stopping & starting
up maven + glassfish/jersey with an empty web app inside.
> 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.
I wonder if we implemented the JRebel listener which is notified of
each class changed; we could do a quick look at the class and see if
its a resource class?
e.g. something like this - reload Jersey if any class changes which
matches one of these conditions...
* if the class has any JAXRS annotations (mostly @Path I"d have thought)
* we have detected that the class has already been loaded as part of
JAXRS URI namespace (i.e. we've already detected it can be returned by
a sub resource)
* its annotated with @XmlRootElement or other relevant JAXB
annotations (so we can force the reload to deal with any JAXB issues).
Its not the end of the world if we're a little over zealous. (e.g. if
the class is within the configured JAXRS packages reload - whether its
actually used as a resource bean or not). Nor if we miss something now
and again (users can always stop/start their web app if they are
unsure).
But if we can get most things reloading for 90% of use cases am sure
it'll make hacking Jersey web apps much more rapid.
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/