can vaadin push to client app

hi all,
| recently started a project with vaadin, and the most important thing is that server can at any time modify any element on client. It can be in response to a user action (that’s easy) or because there is a server script running that has handle to component and is modifying how the component looks or is adding more components to it.

using vaadin-6.4.4 I made a simple app that sets main window with a label and a button.
when the button is clicked I create a second window and I add this window as a popup to main window. In same on-click-button-callback I run a separate thread on the server side that has a reference to the second window and in run-while loop I want to update the second window’s caption or other properties.

ok nothing happens. :slight_smile: - is this possible?

then I though that XHR is a problem so I decided to switch to dontPush plugin (I already talked to Matti - thanks - but I still has few problems so I dont want to bother him). upgraded vaadin to 6.5-20101113.010548-33 and followed
, replaced


I ve found in dontpush.jar and mvn clean vaadin:update-widgetset install. when I start jetty I have

Nov 16, 2010 12:43:40 PM com.vaadin.terminal.gwt.server.AbstractApplicationServlet checkProductionMode
Nov 16, 2010 12:44:06 PM com.vaadin.terminal.gwt.server.AbstractApplicationServlet serveStaticResourcesInVAADIN
INFO: Requested resource [VAADIN/widgetsetsorg.vaadin.dontpush.widgetset.DontpushWidgetsetorg.vaadin.dontpush.widgetset.DontpushWidgetset.nocache.js]
not found …

[/code] so this is true as I dont have anything in target\vaadin-web\VAADIN\widgetsets\ folder

so probably im still doing something wrong, and the msg in console sounds to me that it looks for flex rather than native websocket. im running this on latest chrome browser.

the other question is If I can do what I want using vaadin

thanks for any feedback


You’re right, you need to use some push add-on to do that. Currently there are two: DontPush and IcePush.

As you noticed DontPush uses WebSocket and is in principle a bit more advanced. However, it’s still quite experimental and can be hard to set up (I’m told, I have not trie myself) - Matti could help you, but he’s away right now, I’ll tell him to take a look when he has time. However, to me it seems you might just have a compile problem, but I have not been using Maven either, so I will not comment further :-
In the mean time, IcePush might be easier to set up…

Also, one important thing: when the application is updated by a separate thread, you must synchronize on the application instance before doing the changes (i.e synchronized (application) { label.setValue(“updated”); }), otherwise changes might get lost, or other strange things.

Best Regards,

well I read about IcePush as well but I want to be as html5 compliant as possible,

OK so there is something Im doing wrong with setting up vaadin and GWT in maven, could someone help me on this?

I will read about that in vaadin’s book further

I manage to configure dont push and it works fine.

the problem was that running it from maven - with mvn jetty:run - it looks for VAADIN folder in source root path rather than target.

the other problem was that I should add initial params to my servlet declaration that points to created gwt.file where I point to dontpush widgetset - but it wasnt clearly described in



<?xml version="1.0" encoding="UTF-8"?>
   "-//Google Inc.//DTD Google Web Toolkit 1.7.0//EN"
    <inherits name="org.vaadin.dontpush.widgetset.DontpushWidgetset"/>
    <inherits name="com.vaadin.terminal.gwt.DefaultWidgetSet" />


As said by Marc, I’m actually on a sick leave right now (my ankle was operated few days ago), but I guess it is good time to learn some thing new. With those nice drugs they give you after operation, it should be really easy to find “the flow” :wink:

To spend my time I tried to set up the DontPush add-on with maven. And there indeed was some traps on the way. Some of them might have been easily avoided if had used maven more before.

I started with vaadin-archetype-clean as instructed by the wiki page:

The very first thing was to switch to 6.5 nightly builds. I uncommented snapshots repositories and defined the vaadin version 6.5-SNAPSHOT.

Next I wanted to make sure I can build a widgetset with it. First followed the instructions from the Directory. I know I’d need GWT 2.1.0 so I uncommented GWT dependency and set the version version to 2.1. First problem was here. The get plugin wasn’t compatible with GWT 2.1.0. With little googling and studying I set the gwt-maven-plugin version to 2.1-SNAPSHOT. When I realized that with maven I also need to create the Widgetset.gwt.xml file stub by myself I finally managed to compile the widgetset.

If course this wasn’t enough. The vaadin archetype uses ancient 6.x jetty by default. Just changing the jetty version to 7.2.0.v20101020 didn’t work. At some point they have renamed maven-jetty-plugin to jetty-maven-plugin. I also stripped away the version from that plugin, and some hackie settings related to some ancient maven-jetty-plugin. Also noticed that your culprit, that the webAppSourceDirectory needed to be overridden to make GWT scripts available.

Finally got it working with attached pom file. Some minor changes was also needed to the web.xml (the special servlet and widgetset) was needed.

What a fight. I have heard lots of good about maven, but IMO jee eclipse spiced with our eclipse plugin was a much easier in this case. Partly this is of course our fault because our incomplete maven support. I hope it isn’t this much of a head ache with the stable branch.

11505.xml (4.43 KB)

heh im using intelliJ :] so well eclipse … hym :slight_smile:

jeah vaadin 6.5 was a struggle but easily you can install it by yourself :slight_smile:
anyway the key point is to be sure that xx.gwt.xml is created that points to dontpush widgetset and that is not clear when you read vaadin’s wiki page.

We are going to use this plugin a lot right now so if you want feedback on that probably I can do something about it :slight_smile:

thanks for help

While you are fighting with Maven, I will throw another one at you: you will see more and more people that will need, because of this whole “social” phenomenon, to combine, in a

  • a nice classical webapp
  • a nice mobile app
  • push / websockets

We may therefore need a way to have two servlets (one webapp, one mobile) with different widgetsets, running in the same webapp. Currently I have half a dozen add-ons in my webapp, and I don’t want need that many in my touchkit app, and currently I haven’t found a way to build two widgetsets and point each servlet to the proper widgetset.

Is the problem building the widgetsets with Maven? I assume everything else should work simply by giving the correct init parameters to each servlet in your web.xml.

You’ll probably want to have the widgetsets in separate packages in this case, although it might not be necessary in all cases. Then tell vaadin-maven-plugin not to edit one (or any) of the widgetsets by adding a comment with the string “WS Compiler: manually edited” in the widgetset module (.gwt.xml). No other changes should be required e.g. to vaadin-archetype-sample, you just need to add the “inherits” lines manually.

You could even comment out vaadin-maven-plugin from your pom.xml if you want to avoid accidentally modifying widgetsets.

hej all, Im wondering if you tried dont push with other browsers than google chrome.

in firefox I can see that new connection was establish but my app is not loaded … so I dont know what is going on ;(


Apparently the latest version with flash fallback for IE has broken FF. FF4 seems to work ok. If you need a working version for FF only, use the older version. Otherwise you’ll need to give me some time to fix it or patch it yourself. Next time I work on this project I’ll try to make loading of fallback JS/flash conditional too.

There is also a client side synchronization issue that may cause “loading indicator” to stay visible although server response is not actually pending.

BTW. Jean-Francois, I managed to solve one obstacle to your dream app. I mailed Steve that mobile Safari should support web-sockets. He responded “Soon.” and gave us ios 4.2 this week :slight_smile: I just tried it and it seams to work. I’d expect Android to follow soon.