On Mar 17, 2010, at 12:19 PM, James Strachan wrote:
> 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.
OK. I anticipate we should be able to do something like:
public class Reloader implements ContainerNotifier, ReloadListener {
@PostConstruct
public void postConstruct() {
// Not sure this can be performed in the constructor
ReloaderFactory.getInstance().addReloadListener(this);
}
// Synchronized in case JRebel notifications while ContainerListener
// is being added.
private final List<ContainerListener> ls =
Collections.synchronizedList(new ArrayList<ContainerListener>());
public void addListener(ContainerListener l) {
ls.add(l);
}
// JRebel notification methods
... ...() {
for (ContainerListener l : ls) {
l.onReload();
}
}
}
Do you know if JRebel is available from a maven repo?
> (BTW its renamed from JavaRebel to JRebel - I guess due to
> trademark issues).
>
Ah yes :-)
>
>> 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.
>
Agreed.
>
>> 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.
>
Yes, i think we can tweak things in this regard once the basic system
is in place.
Paul.