Interested in Remote Method Calls via JS in JSF?
Tuesday, September 21, 2010 |One of the nicest enhancements to the JSF specification that 2.0 brought was the inclusion of native Ajax support. It is now extremely simple to Ajaxify a JSF application. One thing that it lacks, though, is the ability to call arbitrary methods on JSF (or CDI?) Managed Beans. There is a project that offers that kind of functionality, and it’s been around for years: Direct Web Remoting. I’ve used this library at times and have found it to be really useful in certain situations. That got me to wondering, Should this kind of functionality be a first class citizen of JSF? To help us decide, let’s take a quick look at how DWR works.
Once you have DWR configured to work (warning: those docs might be slightly out of date, if memory serves me), you have to tell DWR what to expose. I prefer the annotation-based approach (condensing, here, the DWR documentation, with some modifications):
1
2
3
4
5
6
7
8
9
10
11
12
13
@ManagedBean
@SessionScoped
@RemoteProxy
public class RemoteFunctions {
@RemoteMethod
public int calculateFoo() {
return 42;
}
public String calculateBar() {
return "Life, the universe, and everything"
}
}
For a class like this, DWR will expose RemoteFunctions.calculateFoo(), but will not expose RemoteFunctions.calculateBar(). With DWR, you must explicitly mark a method as remoteable (is that a word? : ) or you won’t have access to it.
On the client side, you would put something like this on your page:
1
2
<script type: "text/javascript" src="[WEBAPP]/dwr/interface/RemoteFunctions.js"/>
<script type: "text/javascript" src="[WEBAPP]/dwr/engine.js"/>
With those two declarations, you would then be able to call the JSF Managed Bean via:
1
2
3
RemoteFuctions.calculateFoo(function(str) {
alert(str);
});
While this isn’t a very exciting example, it should highlight the type of interaction DWR enables. It offers a great deal more flexibility with things like RBAC and Object conversion (i.e., DTOs).
I’ve found this to be a very nice library that neatly solves certain types of asynchronous issues. The question I have, though, is, as stated above, "Should this be added to the JSF specification?" Ed Burns, the JSF spec lead, is pretty vocal in his assertion (with which I tend to agree) that specs aren’t primarily for innovating but for standardizing (which is not to say that it can’t be done at all, of course, but great care must be taken with unproven techniques, technologies, etc). His approach with JSF 2 was to look at the field of web application frameworks and see what works and what doesn’t, and what might be a good addition to JSF. With that approach in mind, is DWR-like functionality a good candidate for JSF 2.next? Please feel free to comment below. While I await responses, we’ll see if I can hammer out a proof-of-concept in the Mojarra tree. :)
My name is Jason Lee. I am a software developer living in the middle of Oklahoma. I’ve been a professional developer since 1997,
using a variety of languages, including Java, Javascript, PHP, Python, Delphi, and even a bit of C#. I currently work for Red Hat
on the WildFly/EAP team, where, among other things, I maintain integrations for some MicroProfile specs, OpenTelemetry, Micrometer,
Jakarta Faces, and Bean Validation. (Full resume 