DWR comes as a simple jar file and a few lines to add to your web.xml file to configure the remoted classes. In a web page you add a couple of <script> tags to indicate which classes you wish to import and can then call your Java code directly from Javascript. More detailed instructions are available on the DWR site.
The Javascript works by dynamically creating an iframe through which it calls the DWR servlet with instructions about what Java code to call. The DWR servlet marshalls the parameters, calls the server-side Java code and returns the reply to the iframe, which triggers an onload, which returns the reply to the calling Javascript.
Direct Web Remoting home page
Editorial Note: These days we are seeing more use of the XML HTTP Request object
-
Direct Web Remoting: Call server-side Java from JavaScript (40 messages)
- Posted by: Joe Walker
- Posted on: December 11 2004 07:04 EST
Threaded Messages (40)
- Direct Web Remoting: Call server-side Java from JavaScript by Paul Danckaert on December 13 2004 09:56 EST
- Direct Web Remoting: Call server-side Java from JavaScript by Vijayan Sampath on December 13 2004 10:16 EST
- Direct Web Remoting: Call server-side Java from JavaScript by Andrew Douglas on December 13 2004 11:08 EST
- Security concerns by Joe Walker on December 13 2004 05:48 EST
- Direct Web Remoting: Call server-side Java from JavaScript by Sarath Chandra Kummamuru on December 15 2004 02:39 EST
- DWR Reverse AJAX and native XMLHttpRequest issues in IE6.0 by Anant Agarwal on September 01 2006 05:09 EDT
- Google suggest by Fredrik Holmqvist on December 13 2004 10:03 EST
- Google suggest by Konstantin Ignatyev on December 13 2004 10:12 EST
-
Google suggest by Fredrik Holmqvist on December 13 2004 10:45 EST
-
Google suggest by Konstantin Ignatyev on December 13 2004 10:58 EST
- then again, it's a beta by Bertrand Le Roy on December 13 2004 02:45 EST
-
Works for me by Donald Duck on December 13 2004 03:57 EST
- Works for me by Konstantin Ignatyev on December 13 2004 04:30 EST
- Google suggest by L K on December 14 2004 06:29 EST
-
Google suggest by Konstantin Ignatyev on December 13 2004 10:58 EST
- Unleaded fuel only by Michael Jouravlev on December 13 2004 10:59 EST
-
Google suggest by Fredrik Holmqvist on December 13 2004 10:45 EST
- Google suggest by Konstantin Ignatyev on December 13 2004 10:12 EST
- the XML HTTP Request object by Gabriel K. on December 13 2004 10:10 EST
- the XML HTTP Request object by Sarath Chandra Kummamuru on December 15 2004 02:41 EST
- Direct Web Remoting: Call server-side Java from JavaScript by eisen hower on December 13 2004 11:06 EST
- DWR vs XMLRPC? by Ignacio Napal on December 13 2004 11:13 EST
- DWR vs XMLRPC? by Joe Walker on December 13 2004 18:13 EST
- xmlrpc + javascript by Henrique Steckelberg on December 13 2004 11:20 EST
- xmlrpc + javascript by analog boy on December 13 2004 13:57 EST
- public super methods? by Julian Hall on December 13 2004 15:35 EST
- Use java applet or java desktop application instead by bad mASH on December 13 2004 16:56 EST
- Use java applet or java desktop application instead by Konstantin Ignatyev on December 13 2004 17:09 EST
-
Use a java applet to replace XMLHTTPRequest? NO! by java user on December 13 2004 05:47 EST
- Use a java applet to replace XMLHTTPRequest? NO! by Mark N on December 14 2004 07:46 EST
- Use a java applet to replace XMLHTTPRequest? NO! by bad mASH on December 14 2004 12:24 EST
- Re: Use a java applet to replace XMLHTTPRequest? NO! by adel jams on December 21 2006 06:42 EST
- Use java applet or java desktop application instead by Mark N on December 14 2004 07:43 EST
-
Use a java applet to replace XMLHTTPRequest? NO! by java user on December 13 2004 05:47 EST
- Use java applet or java desktop application instead by Stefan Leut on December 16 2004 05:14 EST
-
Reminds me of older times by J. Alkjaer on December 23 2004 01:14 EST
- Reminds me of older times by Konstantin Ignatyev on December 23 2004 10:43 EST
-
Reminds me of older times by J. Alkjaer on December 23 2004 01:14 EST
- Use java applet or java desktop application instead by Konstantin Ignatyev on December 13 2004 17:09 EST
- Direct Web Remoting: Call server-side Java from JavaScript by Nils Kilden-Pedersen on December 13 2004 23:26 EST
- Demos by Joe Walker on December 14 2004 05:15 EST
- Great tool! by Thang Tran Vinh on December 14 2004 11:02 EST
- Demos by Joe Walker on December 14 2004 05:15 EST
- Direct Web Remoting: Call server-side Java from JavaScript by Nils Kilden-Pedersen on December 13 2004 23:32 EST
- Similar Technology by Klaus Berberich on December 14 2004 14:23 EST
- Graceful degrading by Rob Beardow on December 14 2004 17:53 EST
- this rocks by mike wong on January 26 2005 06:04 EST
-
Direct Web Remoting: Call server-side Java from JavaScript[ Go to top ]
- Posted by: Paul Danckaert
- Posted on: December 13 2004 09:56 EST
- in response to Joe Walker
Anybody have a demo site of this project in action? I'm a big fan of the JavaScript driven XML/RPC or SOAP interface to reduce bandwidth usage, and to improve the user response/experience. Last time I tried to build it out, I had such a hassle with IE that I finally tossed it out, but perhaps this project would help to cover all of that? So, any demos of this? -
Direct Web Remoting: Call server-side Java from JavaScript[ Go to top ]
- Posted by: Vijayan Sampath
- Posted on: December 13 2004 10:16 EST
- in response to Paul Danckaert
Isn't this quite similar to JSRS ??? -
Direct Web Remoting: Call server-side Java from JavaScript[ Go to top ]
- Posted by: Andrew Douglas
- Posted on: December 13 2004 11:08 EST
- in response to Paul Danckaert
I just used the Google bit on Firefox 1.0 and it worked beautifully. Joe, I also looked over some of your website. You bring up the caveat to keep in mind security concerns when using your project. I was hoping you might expand on that a little bit. We could use this to access a java class to retrieve data from a database table or a session bean to access data from a database table: what would the security concerns be and which would be a better choice from your product's view? Also, we were thinking about accessing a web service through a method call in our java with your product (so we could simply display the retrieved info without submitting), any experience with this? Sorry if these questions seem simplistic to folks, but you make the implementation of your product so simple, we thought you'd probably want some of us less experienced folk to use it as well. -
Security concerns[ Go to top ]
- Posted by: Joe Walker
- Posted on: December 13 2004 17:48 EST
- in response to Andrew Douglas
You just need to think for a while about the class you are exposing and check that it's methods are all ones you really want to expose.
If you were to randomly add classes without thinking about what methods you were exposing then you could discover that you'd given access to more functionallity than you meant to.
That's what the warning was about - I'm a bit paranoid about security so I wanted to get my caveats in early! -
Direct Web Remoting: Call server-side Java from JavaScript[ Go to top ]
- Posted by: Sarath Chandra Kummamuru
- Posted on: December 15 2004 02:39 EST
- in response to Paul Danckaert
This is an important feature to build Rich Internet Applications and we use it for most of our enterprise applications for flicker free UI.
It is heartening to see that others are also thinking on similar lines.
We call them DataIslandServices where we identify UI components in the HTML and use IFrames to populate the only a portion of the Page without refreshing the complete page.
Gives a strong statement to our clients who say (using a thick client application is so much more easier because i donot have to see a complete page refresh).
Sarath. -
DWR Reverse AJAX and native XMLHttpRequest issues in IE6.0[ Go to top ]
- Posted by: Anant Agarwal
- Posted on: September 01 2006 05:09 EDT
- in response to Paul Danckaert
Hi All, I have got to make reverse ajax work with DWR using Jetty with Continuations server.The code work fines in FireFox/1.5.0.2 but there are issues in IE 6.0 of the Jetty's long XMLHttpRequest being breaking out in between and the changes made in data at the server side being getting lost. Does anyone has an idea how to Disable Native XMLHttpRequest in IE 6.0 as I feel that it is creating problems???? To be specific I am writing a Javascript object from the server side to the client side by finding the script session and giving the Javascript function name at the server side. -
Google suggest[ Go to top ]
- Posted by: Fredrik Holmqvist
- Posted on: December 13 2004 10:03 EST
- in response to Joe Walker
-
Google suggest[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: December 13 2004 10:12 EST
- in response to Fredrik Holmqvist
http://www.google.com/webhp?complete=1&hl=enIt rocks.
For a while.
As I am concerned about cross browser compatibility I do not trust JScript for anything but simple things because JS works differently in different browsers and its behavior may change quite suddenly as browser patches get issued and applied. -
Google suggest[ Go to top ]
- Posted by: Fredrik Holmqvist
- Posted on: December 13 2004 10:45 EST
- in response to Konstantin Ignatyev
Well, it's not the JavaScript that is the problem it's the browser implementations. So far they have not been very compatible, so I understand your comment. Anyway I was talking about 'Google Suggests' when I said it rocks. -
Google suggest[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: December 13 2004 10:58 EST
- in response to Fredrik Holmqvist
Well, it's not the JavaScript that is the problem it's the browser implementations.
So far they have not been very compatible, so I understand your comment. Anyway I was talking about 'Google Suggests' when I said it rocks.
I understand.
Google suggest does not work in Konqueror,popup looks corrupted in my Firefox on Windows, and there is no guarantee that it will work after some patch.
I cannot call it rock solid.
(Although the idea is nice and it looks good in IE and Opera) -
then again, it's a beta[ Go to top ]
- Posted by: Bertrand Le Roy
- Posted on: December 13 2004 14:45 EST
- in response to Konstantin Ignatyev
Google suggest is still a beta, so it is understandable that it is not "rock solid".
Such a feature is a nice to have, but it should (and probably will) degrade gracefully for browsers that do not support XmlHttp.
Give them time. -
Works for me[ Go to top ]
- Posted by: Donald Duck
- Posted on: December 13 2004 15:57 EST
- in response to Konstantin Ignatyev
Firefox 1.0 on XP. Works like a champ. -
Works for me[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: December 13 2004 16:30 EST
- in response to Donald Duck
Firefox 1.0 on XP. Works like a champ.
Actually, corrupted look that I mentioned caused by the way Jscript handles HTML rendering. Try customizing XP theme by changing fonts and screen DPI then you will see how Jscript popups and menus look like :).
While it has nothing to do with remoting itself such visualization problem does not add confidence in the client side Jscript. -
Google suggest[ Go to top ]
- Posted by: L K
- Posted on: December 14 2004 06:29 EST
- in response to Konstantin Ignatyev
popup looks corrupted in my Firefox on Windows,
What wersion of Firefox are you using ?
It looks ok in 1.0 ... -
Unleaded fuel only[ Go to top ]
- Posted by: Michael Jouravlev
- Posted on: December 13 2004 10:59 EST
- in response to Konstantin Ignatyev
As I am concerned about cross browser compatibility I do not trust JScript for anything but simple things because JS works differently in different browsers and its behavior may change quite suddenly as browser patches get issued and applied.
MSIE 6.0 is available for 3 years already, so each and everyone on Windows platform must use this latest version if they want to use browse modern websites. Firefox 1.0 is released this November for most popular platforms, it is compatible and it is free, so there should not be problem here as well. When 20 years ago when they had started to sell cars with catalythic converters, it was commonly accepted that these cars take only unleaded fuel. How software is different? -
the XML HTTP Request object[ Go to top ]
- Posted by: Gabriel K.
- Posted on: December 13 2004 10:10 EST
- in response to Joe Walker
These days we are seeing more use of the XML HTTP Request object.
As in : Google sugest
It gives you suggestions while typing. Some kind of completion. It seems to work with a service called by an XMLHttpRequest javascript object. Not sure if it is the most usefull example but it is rather impressive.
One can imagine using this solution for adress completion: give me your post post and I give you a list of towns. -
the XML HTTP Request object[ Go to top ]
- Posted by: Sarath Chandra Kummamuru
- Posted on: December 15 2004 02:41 EST
- in response to Gabriel K.
I found some problems with XMLHTTPRequest object on Mozilla, but works so well on IE. Any one knows of making it work on mozilla. -
Direct Web Remoting: Call server-side Java from JavaScript[ Go to top ]
- Posted by: eisen hower
- Posted on: December 13 2004 11:06 EST
- in response to Joe Walker
Google Search uses "IFRAME" to call remote server instead of XML Httprequest object. PLS check google's JS file. -
DWR vs XMLRPC?[ Go to top ]
- Posted by: Ignacio Napal
- Posted on: December 13 2004 11:13 EST
- in response to Joe Walker
I am using XML-RPC libraries (www.xmlrpc.org) for connecting Javascript at Client side with Java at Server side, and it works very fine.
Which is the advantage of using DWR?
Thanks!
Ignacio. -
DWR vs XMLRPC?[ Go to top ]
- Posted by: Joe Walker
- Posted on: December 13 2004 18:13 EST
- in response to Ignacio Napal
I am using XML-RPC libraries (www.xmlrpc.org) for connecting Javascript at Client side with Java at Server side, and it works very fine. Which is the advantage of using DWR?
I'm not an XML-RPC expert but there would seem to be 2 benefits. Fisrtly the Javascript is much easier, from the examples the following Javascript: "Date.hashCode(reply0); " calls the hashCode method on a java.util.Date object and returns the answer to the reply0 method.
Secondly DWR is small a lean, so it is very quick. I doubt that you could get to Google suggest speeds with XML-RPC, but maybe you have a chance with DWR. -
xmlrpc + javascript[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: December 13 2004 11:20 EST
- in response to Joe Walker
I've used http://jsolait.net/examples/xmlrpc/ and loved it. It felt like client-server programming in a web environment, which was great and worked nicely for me. If SVG would really catch on, this could be the final RIA solution: SVG 1.2 + Script + Browser...
Regards,
Henrique Steckelberg -
xmlrpc + javascript[ Go to top ]
- Posted by: analog boy
- Posted on: December 13 2004 13:57 EST
- in response to Henrique Steckelberg
we tried to use an xml-rpc solution too, the only problem was that we had to support older browsers. We ended up using a solution based on Bob Lee's livescript (http://crazybob.org/index.jsp) which allowed similar functionality even on old browsers.
The only disadvantage of this method is that you are limited by how much information you can send because it uses cookies. However, you can make several simultaneous requests which helps to get around that problem.
Also, we didn't test on low-bandwidth lines, I'm not sure how well it would work on 56k lines. -
public super methods?[ Go to top ]
- Posted by: Julian Hall
- Posted on: December 13 2004 15:35 EST
- in response to Joe Walker
I gave this a quick spin, but I noticed that a bean's parent public methods aren't exposed? Is this done on purpose, or am I missing something? -
Use java applet or java desktop application instead[ Go to top ]
- Posted by: bad mASH
- Posted on: December 13 2004 16:56 EST
- in response to Joe Walker
Javascript is flaky. Its functionality depends on the version of browser, type of browser, security settings ( allows pop up etc.), etc. etc. Not to mention that debugging and maintaining javascript is extremely painful
If you need a rich client -- used JDNC or Java applet. YOu have a controlled rendering environment and the code is easier to read. -
Use java applet or java desktop application instead[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: December 13 2004 17:09 EST
- in response to bad mASH
Javascript is flaky. Its functionality depends on the version of browser, type of browser, security settings ( allows pop up etc.), etc. etc. Not to mention that debugging and maintaining javascript is extremely painfulIf you need a rich client -- used JDNC or Java applet. YOu have a controlled rendering environment and the code is easier to read.
Agreed.
Applets would be a preferable solution if they were truly supported by JavaWebStart and if a central repository of 3rd party libraries was available to prevent clients from downloading the same libraries all over again! -
Use a java applet to replace XMLHTTPRequest? NO![ Go to top ]
- Posted by: java user
- Posted on: December 13 2004 17:47 EST
- in response to Konstantin Ignatyev
My client is living through the hell of maintaining java applets that make http requests (in the background of the webapp). The mystery browser lock-ups, wait times, Sun vs MS JVM, etc, is not fun. We are recommending that they replace the applet "back door communication" with something lighter like HTTPRequest in JS. Google Suggest is inspiring. -
Use a java applet to replace XMLHTTPRequest? NO![ Go to top ]
- Posted by: Mark N
- Posted on: December 14 2004 07:46 EST
- in response to java user
My client is living through the hell of maintaining java applets that make http requests (in the background of the webapp). The mystery browser lock-ups, wait times, Sun vs MS JVM, etc, is not fun. We are recommending that they replace the applet "back door communication" with something lighter like HTTPRequest in JS. Google Suggest is inspiring.
What are they using now for "back door" communication. I've used HTTPRequest with applets and applications successfully for years.
And Sun vs MS JVM? Just say no to MS JVM. No matter how good it might have been - it is time to bury it. -
Use a java applet to replace XMLHTTPRequest? NO![ Go to top ]
- Posted by: bad mASH
- Posted on: December 14 2004 12:24 EST
- in response to java user
My client is living through the hell of maintaining java applets that make http requests (in the background of the webapp). The mystery browser lock-ups, wait times, Sun vs MS JVM, etc, is not fun. We are recommending that they replace the applet "back door communication" with something lighter like HTTPRequest in JS. Google Suggest is inspiring.
This sounds more like a poorly coded applet.
MS vs. Sun JVM -- say no to MS JVM -- use applets that run in Sun's Java plugin. -
Re: Use a java applet to replace XMLHTTPRequest? NO![ Go to top ]
- Posted by: adel jams
- Posted on: December 21 2006 06:42 EST
- in response to java user
Well, It is a Yes! Use Applet if you like it! I have developed a light <5k applet to communicate with server and call its functions from javascript. This solution is working on various systems. If I face problem, I just install java plugin (1.3.1_07) and the applet works fine! Adil -
Use java applet or java desktop application instead[ Go to top ]
- Posted by: Mark N
- Posted on: December 14 2004 07:43 EST
- in response to Konstantin Ignatyev
... and if a central repository of 3rd party libraries was available to prevent clients from downloading the same libraries all over again!
Sounds a bit like dll hell. Good idea, not so good when it is actually implemented. -
Use java applet or java desktop application instead[ Go to top ]
- Posted by: Stefan Leut
- Posted on: December 16 2004 05:14 EST
- in response to bad mASH
Javascript is flaky. Its functionality depends on the version of browser, type of browser, security settings ( allows pop up etc.), etc. etc. Not to mention that debugging and maintaining javascript is extremely painful
Javascript is NOT flaky. All browser Javascript engines I knew are working identically. The case is that DOM implementations differ in various browsers, so decision to build thick cross-browser client based on default browser capabilities is unwise. This is doable, but it is a real pain.
If you are bound to the specific browser (which is often for intranet web applications), rich functionality based on Javascript works well though -
Reminds me of older times[ Go to top ]
- Posted by: J. Alkjaer
- Posted on: December 23 2004 01:14 EST
- in response to Stefan Leut
Somehow that reminds me of "windows GUI programming is so different from the X Windows programming"
Anybody else who gets the feeling that the software industry moves in circles ;-) -
Reminds me of older times[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: December 23 2004 10:43 EST
- in response to J. Alkjaer
Somehow that reminds me of "windows GUI programming is so different from the X Windows programming" Anybody else who gets the feeling that the software industry moves in circles ;-)
I would say its movement is a spiral, but I am not quite sure about direction along Z-axis… seems to be going south :) -
Direct Web Remoting: Call server-side Java from JavaScript[ Go to top ]
- Posted by: Nils Kilden-Pedersen
- Posted on: December 13 2004 23:26 EST
- in response to Joe Walker
From the website:The best way to get started is to nick the code from the demo pages
What demo pages? -
Demos[ Go to top ]
- Posted by: Joe Walker
- Posted on: December 14 2004 05:15 EST
- in response to Nils Kilden-Pedersen
From the website: The best way to get started is to nick the code from the demo pages
<br/>
What demo pages?
I was referring to the pages in the previous steps - the advantage of that is that it is customized to your circumstances.
However I'm working on getting a live demo working. -
Great tool![ Go to top ]
- Posted by: Thang Tran Vinh
- Posted on: December 14 2004 11:02 EST
- in response to Joe Walker
Wow, I must say "this is really cool!". It is what I am looking for. It is best suited for web sites that have progress bar, tree based component, dynamic user interative feature..It helps us ease the pain of javascript stuff.
Thank you for great tool, Joe!
Regards,
Thang -
Direct Web Remoting: Call server-side Java from JavaScript[ Go to top ]
- Posted by: Nils Kilden-Pedersen
- Posted on: December 13 2004 23:32 EST
- in response to Joe Walker
Would this work with an <object/> instead of <iframe/>, since iframe has been deprecated? -
Similar Technology[ Go to top ]
- Posted by: Klaus Berberich
- Posted on: December 14 2004 14:23 EST
- in response to Joe Walker
There is a product which is from as far as I can see based on the same idea: Casabac (www.casabac.com). We use them to create web based applications that have a feeling like rich client applications. On the frontend side this is done by a lot of JS, which communicates over a hidden frame with Java based adapter logic. Still, we don't have to care about it, since Casabac handles all the JS<->Java adapter stuff and we can focus on writing the adapters. After struggeling a lot with all the web frameworks around we found this to be a real booth in development speed - at least when it comes to intranet applications. And the users like things like context menus and non-flickering pages in a browser based application.
Klaus -
Graceful degrading[ Go to top ]
- Posted by: Rob Beardow
- Posted on: December 14 2004 17:53 EST
- in response to Joe Walker
This looks like a nifty piece of technology (implementation and concept).
You could have your client side validation logic actually done on the server (instead of writing JS validation + server side validation, duplicating logic).
Your application could then degrade gracefully i.e. if JS is on and the version is supported, the bells and whistles can be used (seach suggestion ala google suggest, client side validation, pre-population etc).
If JS is off or not supported, application runs like a normal web app w/ server side validation etc. -
this rocks[ Go to top ]
- Posted by: mike wong
- Posted on: January 26 2005 06:04 EST
- in response to Joe Walker
Sure this one rocks! I've been finding a solution like this for some time now.
Thanks